TCP与UDP TCP与UDP

二三层网络传输
文章图片
截屏2020-07-24 下午3.17.54.png TCP TCP需要关注的5个问题

顺序问题
丢包问题
连接维护
流量控制
拥塞控制

TCP头文件，相应的UDP头文件只有源端口号与目的端口号字段

文章图片
TCP头文件 TCP三次握手 [wireshark抓包分析（可进一步了解序号和确认号等问题）]
(https://sq.163yun.com/blog/article/193066493804396544?tag=M_tg_144_70)

文章图片
SYN-SENT.png 说明：
SYN：建立连接请求
FIN：断开连接请求
ACK：应答
LISTEN:服务端处于主动监听的状态
SYN-SENT:连接请求已发送
SYN-RCVD:连接请求已收到
相关问题：
1、为什么需要3次握手？两次不行？（主要第二点）

B收到请求之后不确定自己发送的应答能否达到A(需要一去一回)，因此B不能建立连接，两次握手A是可以建立连接；
复杂情况下，A发送了多次SYN请求才与B建立连接，连接短暂时间断开之后，A之前重复发送的请求到达B，如果两次握手的话，会使得B单向连接，单相思，耗费B的资源。三次握手时，第三次失败，A已建立连接，B未建立连接，似乎也有同样的问题，但是A给B发送数据的时候，B会自动建立连接了。
3次握手除了解决连接问题外，还要解决TCP包序号的问题，即数据传输的时候，数据包的起始序号，序号是每过4ms加1。序号不能从1开始，要确保包序号的唯一性，数据传输是按序号接收的，防止绕远路包序号混淆。

四次挥手

文章图片
ESTABLISHED.png
名字解释

2MSL:MSL是Maximum Segment Lifetime，报文最大生存时间,IP包中有个TTL域，可以经过的最大路由器数，没经过一个减一，为0时丢弃
第二步ASK之后，A已经断开连接不能向B发送数据，反过来是可以的
SYN=1，FIN=1不携带数据，需要消耗掉一个序号。ACK=1可以携带数据，不携带的话不消耗序号

相关问题：
1.为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

如果A收到FIN，发送ACK后马上CLOSED，最后的ACK有可能失败，超时MSL后B会重新发送个FIN给A,此时A就没法回复ACK了。2MSL是第4步加上第三步重发的时间上限，保证可以重发一次，然后A重启2MSL计时器
第三步B多次重发FIN时，由于A已经关闭了，这个端口号可能给其他应用使用了，后面重发的FIN有可能连接到其他应用产生混乱（虽然有包序号做了一层保险）

2、为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

B在收到FIN时，有可能在处理数据发送，先发一个ACK应答，处理完再发送FIN

流量控制根据接收方的窗口大小调整发送方的窗口，TCP头文件中有个窗口大小的字段。

文章图片
接收方

MaxRcvBuffer：最大缓存的量是一个固定的值
接收已确认：表示应用层还未读取的数据
等待接收未确认：就是窗口的大小
当应用层长时间未读取数据时，接收已确认部分空间扩大，相应导致等待接收未确认部分即接收窗口变小，接收端会在ack的头文件中附带变小的窗口大小字段，让发送端缩小发送窗口。

文章图片
发送方窗口控制流程
在以上图示中，接收端6，7有可能会接收失败，假设6接收成功7接收失败，发送端有3种处理重传的方式：

超时重试：如果发送端发送7超过往返的RTT（不断变化的平均值）时间仍然没有收到ACK，发送端就会超时重传一次，如果仍然没有收到，将超时时间设为原来的两倍。存在的问题是超时时间太长，用户等待太久。
快速重传：当接收方收到的序号大于期待的序号时，8比7提前到达，接收方判断7已经丢失，于是在超时重试之前6发送3个冗余的ack，通知发送端重新发送7.
Selective Acknowledgment （SACK）：将缓存地图发送给对方，例如发送ACK6、SACK8、SACK9，可以判断7丢失了

MSL、TTL及RTT的区别

拥塞控制

文章图片
截屏2020-07-24 下午4.16.27.png 【TCP与UDP】LastByteSent - LastByteAcked <= min {cwnd（拥塞窗口）, rwnd（滑动窗口）} ，cwnd与rwnd共同控制发送速度。
一开始TCP连接时，cwnd（拥塞窗口）会指数级增长，到达上限值 ssthresh时，cwnd变成每次加1的线性增长，当出现丢包需要超时重传的现象时，就认为网络已经拥塞了，此时有3种处理方式：

超时重传：将 sshresh 设为 cwnd/2，将 cwnd 设为 1，重新开始慢启动。从高速传输马上停下来，会造成网络卡顿
快速重传算法：当发现中间的一个包丢失时，发送前一个包的3次ACK，要求快速重传，cwnd 减半为 cwnd/2，然后 sshthresh = cwnd。cwnd保持线性增长
TCP BBR 拥塞算法：以上算法还存在两个问题，1.丢包不一定是满了，还有其他原因导致丢包。2.填满了路由的缓存才会出现丢包。BBR算法不是通过丢包的现象来判断是否拥塞，会找到一个平衡点，充满管子就表示拥塞了，而不必充满缓存

文章图片
截屏2020-07-24 下午4.37.46.png