从TCP的“三次握手”和“四次分手”讲起

说起TCP中最常见最重要的问题当然就是“三次握手”、“四次分手”了。在此之前，我们先来预热一下TCP的基本知识。

TCP报文段结构

Source Port、Destination Port：即源端口号和目的端口号，被用于多路复用/多路分解来自或送到上层应用的数据。
Sequence Number(32 bit)：是包的序号，用来解决网络包乱序（reordering）问题。
Acknowledgment Number(32 bit)：是确认号，用于确认收到，用来解决不丢包的问题。
Window(16 bit)：也称接收窗口，该字段用于流量控制，指示接收方愿意接收的字节数量。以后会谈到。
Offset(4 bit)：即首部长度字段，指示了以32比特的字为单位的TCP首部长度，由于TCP选项字段的原因，TCP首部的长度是可变的。
TCP Options：选项字段，用于发送方和接收方协商最大报文段长度（MSS）时，或在高速网络环境下用作窗口调节因子时使用。
TCP Flags(6 bit)：即TCP的标志字段，就是包的类型，主要是用于操控TCP的状态机。

关于TCP报文头部的标志位

• URG 紧急指针
• ACK 确认序号
• PUSH 接收方应当尽快将这个报文段交给应用层
• RST 重置。重建链接
• SYN 同步序号用来发起一个连接
• FIN 完成发送

---

正确理解序号与确认号

首先要明白TCP将数据看成是一个无结构、有序的字节流。发送端的TCP会隐式地对数据流中的每一个字节编号。一个报文段的序号指的是该报文段首字节的字节流编号。
举个例子，假设主机A上的一个进程向通过一条TCP连接向主机B上的一个进程发送一个数据流。假定数据流由一个包含500000字节的文件组成，其MSS（TCP数据包每次能够传输的最大数据分段）为1000字节，数据流的首字节编号是0，该TCP将为该数据流构建500个报文段，给第一个报文段分配序号0，第二个报文段分配序号1000，第三个分配为2000……每一个序号被填入相应的TCP报文段首部的序号字段中。
注意的是，每一个报文段的大小不一定是MSS，而且下一个要发送的报文段大小还取决于接收方的窗口大小，这在之后的流量控制会谈到。

由此我们试想一下，当已知一个TCP连接中正发送一个包的序号为1500，我们可以知道，该端已经发送了1500字节的数据。所以，序列号又可以记忆为：当前端已经发送的数据位数，是否确认送达这还不一定。
确认号的增加是和传输的字节数相关的，除了数据占用字节数之外，每发送一次有效标志位SYN或FIN也算1位数据。

现在谈一下确认号。由于TCP是全双工通信的，同一条TCP连接的两端会相互接收和发送数据。当主机B收到来自于主机A的一个报文段，需要给主机A回个信息说明已成功收到，这个信息就是确认号。
主机B填充进报文段的确认号是主机B期望从主机A收到的下一个报文段的序号，或者也可以记忆成：当前端成功接收的数据位数。下面举两个例子，一个是正常情况下的数据传输，一个是出现差错的数据传输。
情况一，假设主机B收到了来自主机A的编号为0~535的所有字节（此报文段序号为0），同时打算发送一个报文段给主机A，其中的确认号字段填充为536。说明主机B等待主机A的数据流中字节编号为536及之后的所有字节，或者也可以理解为，主机B已经成功接收到了536位数据。
情况二，假设主机A向主机B发送了字节编号为0-535，536-899，900-1000的三个报文段（报文段序号为0，536,900）。由于某种原因（报文段丢失），主机B没有收到字节编号536-899的报文段。那么问题来了，由于第三个报文段