23.TCP（二）

Posted 2023-04-06

参考技术A 备注：ISN（Inital Sequence Number）：初始化Sequence Number，发生在建立连接时。

特别注意

Seq：是发送方当前报文的顺序号码。
ack：是发送方期望对方在下次返回报文中给回的Seq。

建立连接需要三次握手

第一次握手：客户端向服务端发送连接请求包，标志位SYN（同步序号）置为1，顺序号码为X=0。

第二次握手：服务端收到客户端发过来报文，由SYN=1知道客户端要求建立联机，则为这次连接分配资源。并向客户端发送一个SYN和ACK都置为1的TCP报文，设置初始顺序号码Y=0，将确认序号(ack)设置为上一次客户端发送过来的顺序号(Seq)加1，即X+1 = 0+1=1。

第三次握手：客户端收到服务端发来的包后检查确认号码(ack)是否正确，即第一次发送的Seq加1（X+1=1）。以及标志位ACK是否为1。若正确，服务端再次发送确认包，ACK标志位为1，SYN标志位为0。确认号码(ack)=Y+1=0+1=1，发送顺序号码(Seq)为X+1=1。Server收到后确认号码值与ACK=1则连接建立成功，可以传送数据了。

断开连接需要四次挥手

提醒：中断连接端可以是Client端，也可以是Server端。只要将下面两角色互换即可。
第一次挥手：客户端给服务端发送FIN报文，用来关闭客户端到服务端的数据传送。将标志位FIN和ACK置为1，顺序号码为X=1，确认号码为Z=1。意思是说”我Client端没有数据要发给你了，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK过来。”

第二次挥手：服务端收到FIN后，发回一个ACK(标志位ACK=1),确认号码为收到的顺序号码加1，即X=X+1=2。顺序号码为收到的确认号码=Z。意思是说“你的FIN请求我收到了，但是我还没准备好，请继续你等我的消息" 这个时候客户端就进入FIN_WAIT状态，继续等待服务端的FIN报文。

第三次挥手：当服务端确定数据已发送完成，则向客户端发送FIN报文，关闭与客户端的连接。标志位FIN和ACK置为1，顺序号码为Y=1，确认号码为X=2。意思是告诉Client端“好了，我这边数据发完了，准备好关闭连接了。”

第四次挥手：客户端收到服务器发送的FIN之后，发回ACK确认(标志位ACK=1),确认号码为收到的顺序号码加1，即Y+1=2。顺序号码为收到的确认号码X=2。意思是“我Client端知道可以关闭连接了，但是我还是不相信网络，怕 Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。“（在TIME_WAIT状态中，如果TCP client端最后一次发送的ACK丢失了，它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭，并且所有的资源(包括端口号)都被释放。）

为什么关闭的时候却是四次挥（握）手？
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

捕获过滤器中填入表达式：host www.cnblogs.com and port 80（80等效于http）
有多个TCP流时在显示过滤器中填入表达式：tcp.stream eq 0 筛选出第一个TCP流（包含完整的一次TCP连接：三次握手和四次挥手）

每条记录都有如下协议层
（1） Frame: 物理层的数据帧概况
（2）Ethernet II: 数据链路层以太网帧头部信息
（3） Internet Protocol Version 4: 互联网层IP包头部信息
（4）Transmission Control Protocol: 传输层的数据段头部信息，此处是TCP
（5） Hypertext Transfer Protocol: 应用层的信息，此处是HTTP协议

摘自： http://www.cnblogs.com/ImBit/p/5513401.html#two.one

TCP协议原理二

文章目录

• 四、滑动窗口
• 二、流量窗口
• 三、拥塞控制

四、滑动窗口

前面我们学习了 确认应答，超时重传，连接管理，这些机制都为我们TCP的可靠性提供了保证，当然在保证TCP的可靠性的同时，传输效率也受到了一定的影响，我们的TCP也将尽可能的提高传输效率，大家注意这里的提高传输效率，实际上是尽量的降低效率的亏损，无论我们如何提高都不可能比UDP这种不考虑可靠性的效率高，我们要做的是尽量让TCP效率高一些。

对于我们基本的确认应答来言，每次发一个数据后都需要收到一个ack后才发下一个数据。

滑动窗口的本质就是批量发送一组数据，然后使用一份时间来等待多个ack，这样就可以大大的提高性能。
窗口大小： 不需要等待，直接可以发送的数据最大的量。
我们在这里并不是等所有的ack到达后，才继续往下发，而是到一个ack就继续往下发一条，操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉。窗口越大，网络的吞吐率就越高。

比如这里我们等待的ack是1001-5000，我们收到了2001这个ack，证明2001之前的数据(1001-2000)已经确定了，我们接下来就可以立即再发一条，也就是5001-6000的数据，此时意味着我们等待的ack的范围就是2001-6000了
上面的情况都是理想状态，那如果出现了丢包了怎么办?
1. ack丢了

如果是ack丢了，我们不做任何处理也没事，为什么? 就需要我们弄清楚ack的含义是什么。
ack代表的是该序号之前的所有数据都确认到达了。
比如我们这里的1001的ack丢失了，但是我们的2001ack顺利到达了，2001到达的含义就是：2001之前的所有数据都确认到达了(1-1000 和 1001-2000都已到达)，2001这个ack已经覆盖了上一个丢失的1001ack的信息了。

2. 数据丢了

我们这里的2001-3000丢包了，接下来3001-4000到达接收方之后，接收方给发送端的ack确认序号仍然是2001，表达的意思就是在索要2001开头的数据，我们可以发下下面的几个ack返回的都是2001，这时候发送端就会发现虽然已经发了许多数据了，但是接收端一直在反复索要2001开头的数据，证明2001-3000是没有收到的需要重传了。
等我们重传2001-3000的数据之后，由于2001-8000的数据都已经接收到了，于是接下来接收端索要的数据就是8001了。
快速重传： 就是我们上述丢包后重传的情况，也可以理解为超时重传机制在滑动窗口场景的变形。
有的同学可能会问到，那这样接收端接收的数据不就乱序了吗？
这个不必担心，因为我们TCP有接收缓冲区，会在缓冲区根据序号进行重新排序。

二、流量窗口

简单理解一下，我们流量窗口就是干涉滑动大小的机制。
随着滑动窗口的变大，我们的传输效率也在变高，但能无限增大吗?

1. 如果无限大，相当于不等ack，那么可靠性能否保证？
2. 窗口太大，会消耗大量的系统资源
3. 接收方的处理能力能否跟得上?

我们接收方的处理能力是我们滑动窗口大小的一个很重要的约束条件，我们流量控制要进行的工作就是根据接收方的处理能力，来协调我们发送方的放松速度。
衡量接收方的处理能力是一个非常复杂的问题，可以从多个角度去衡量，比如去计算我们接受方的处理速度，但这种方式太麻烦了，于是我们这里有一个更简单的方法，就是判断接收方缓冲区的剩余大小。

我们接收方每次接收到数据之后，都需要计算一个水桶剩余的容量，然后将这个值通过ack报文返回给发送方，然后发送方就能根据这个值来决定接下来发送的速率大小(窗口大小)是多少了。

16位的窗口大小是否意味着窗口大小最大是64kb了?
并不是，我们的TCP在选项部分引入了一个窗口扩展因子 ，比如当我们窗口大小已经是64kb了但是仍然不够，于是在选项里的扩展因子写了个2，就代表64kb << 2 == 256 kb，这样就可以动态调整窗口大小了。

由于我们接收端的缓冲区剩余容量是一直动态变化的，所以每次返回的ack的窗口大小也是在不断变化的。

1. 接收端一旦发现自己的缓冲区快满了，会将窗口大小设置成一个更小的值通知发送端
2. 发送端发现会随着接收端ack报文中的窗口大小减小而减慢自己的发送速度
3. 如果接收端缓冲区慢了，就会将窗口设置为0，发送方将不再发送数据，会定期发送一个窗口探测数据段，使接收端发送一个新的窗口大小给发送端

三、拥塞控制

拥塞控制和流量控制共同去决定发送方的窗口大小为多大，我们刚刚学习的流量控制考虑的是接收方的处理能力，而我们拥塞控制考虑的是传输过程中各个结点的处理能力。

我们刚刚只考虑了B的处理能力，越没有考虑这些中间结点的因素，决定A发送速度是有这两者最差的一个决定的，也就是典型的木桶效应。
我们中间的结点是错综复杂的，不太好衡量，但是大佬们总是有办法，想出了一个实验的方式来
测试出一个合适的值。
拥塞控制： 本质上就是通过实验的方式，来逐渐找到了一个合适的窗口大小。

慢启动： 我们可以发现0轮时，窗口大小是1(1不是一字节，而是一个单位，具体代表多少不是我们考虑的范围)，以非常慢的速度发送数据，如果发现没有丢包，就扩大窗口。第一轮窗口大小为2，扩大了一倍，初始阶段，由于窗口大小比较小，只要每一轮不丢包窗口都扩大一倍(指数增长)。
阈值： 因为指数方式增长的很快，为了不增长那么快，引入了一个慢启动的阈值，当拥塞窗口超过这个阈值的时间，不再按照指数增长，而是按照线性方式增长。
在接下来，如果传输过程中一旦出现了丢包，如果是极少量的丢包仅仅触发超时重传，如果大量丢包，我们就认为网络拥堵，到达了发送速率的极限，此时就将窗口大小一次性缩到很小的值，然后重复上述的指数增长和线性增长的过程，因为我们的拥塞窗口不是固定的值，而是一直动态变化的。

流量控制和拥塞窗口共同决定了发送方实际发送的窗口大小(流量控制和拥塞控制的较小值)