1.TCP基本概念
- TCP(Transmission Control Protocol 传输控制协议)是一种面向连接(连接导向)的、可靠的、 基于IP的传输层协议。
2.TCP报文详情
-
源端口（Source Port）：标识哪个应用程序发送，长度为16比特。
-
目的端口（Destination Number）：标识哪个应用程序接收，长度为16比特。
-
序号字段（Sequence Number）：TCP链接中传输的数据流每个字节都编上一个序号，序号字段的值指的是本报文段所发送数据的第一个字节的序号，长度为32比特。
-
确认序列号（Acknowledgment Number）：是期望收到对方下一个报文段数据的第1个字节的序号，即上次已经成功接收到的数据段的最后一个字节数据的序号加1，只有控制位中的ACK标识为1，此字段才有效，长度为32比特。
-
头部长度（Header Length）：长度为4比特，指出TCP报文头部长度，以32比特（4字节）为计算单位，若无选项内容，则该字段为5，即头部为20字节，4比特最大标识15，即TCP头部最长为60字节。
-
保留（Reserved）：必须填0，长度为6比特。
-
控制位（Control bits）：包含以下六种标志位
- URG标志：标识紧急指针（Urgent）是否有效；
- ACK标志：标识确认序列号（Acknowledgement Number）是否有效，携带ACK标识的TCP报文段被称为为确认报文段；
- PSH标志：提示接收端应用程序应该立即从TCP接收缓冲区中读取数据，为接收后续数据腾出空间（如果应用程序不将接收到的数据读走，它们就会一直停留在TCP接收缓冲区中）；
- RST标志：当RST=1时，表示出现连接错误，必须释放连接，然后再重建传输连接，复位比特还用来拒绝一个不法的报文段或拒绝打开一个连接，携带RST标志的TCP报文段被称为复位报文段；
- SYN标志：当SYN=1,ACK=0时，表示请求建立一个连接，携带SYN标志的TCP报文段被称为同步报文段；
- FIN标志：当FIN=1时，表示通知对方本段要关闭连接了，携带FIN标志的TCP报文段被称为结束报文段。
-
窗口（Window）：这个值表明当前接收端可接受的最大的数据总数（以字节为单位），窗口最大为65535字节，长度为16比特。
-
校验和（Checksum）：是一个强制性的字段，由发端计算和存储，并由收端进行验证，在计算校验和时，要包括TCP头部和TCP数据，同时在TCP报文段的前面加上12字节的伪头部，长度为16比特。
-
紧急指针（Urgent）：只有URG标志置1时紧急指针才有效，TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。紧急指针指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面），长度为16比特。
-
选项字段（Options）：可选字段，长度为0-40字节。
3.UDP报文详情
- 源端口（Source Port）：标识哪个应用程序发送，长度为16比特。
- 目的端口（Destination Port）：标识哪个应用程序接收，长度为16比特。
- 长度（Length）：该字段指定UDP报头和数据总共占用的长度，最小的长度为8字节，即UDP头部长度为8字节，由于这个字段的存在，UDP报文总长不可能超过65535字节（包括8字节的头，和65527字节的数据）。
- 校验和（Checksum）：覆盖UDP头部和和UDP数据的校验和，长度为16比特。
4.TCP的建立 - 三次握手
TCP连接建立的详细过程如下：
- 由TCP连接发起方，发送第一个SYN位置1的TCP报文。初始序列号a为一个随机生成的数字，因为没收到过来自接收方的任何报文，所以确认序列号为0；
- 接收方接收到合法的SYN报文之后，回复一个SYN和ACK置1的TCP报文。初始序列号b为一个随机生成的数字，同时因为此报文回复给发起方的报文，所以确认序列号为a+1；
- 发起方接收到接收方发送的SYN和ACK置位的TCP报文后，回复一个ACK置位的报文，此时序列号为a+1，确认序列号为b+1，接收方收到之后，TCP双向连接建立。
5.TCP的序列号与确认序列号
TCP使用序列号和确认序列号字段实现数据的可靠和有序传输
-
假设PC1要给PC2发送一段数据，传输过程如下：
- PC1将全部待TCP发送的数据按照字节为单位编上号。假设第一个字节编号为 “a+1” ，第二个字节的序号为 “a+2” ，以此类推。
- PC1会把每一段数据的第一个字节的编号作为序列号（Sequence number），然后将TCP报文发送出去。
- PC2在收到PC1发送来的TCP报文后，需要给予确认同时请求下一段数据，如何确认下一段数据呢？序列号（如：a+1）+载荷长度（如：12）=下一段数据的第一个字节的序号（a+1+12）。
- PC1在收到PC2发送的TCP报文之后，发现确认序列号为 “a+1+12” ，说明 “a+1” 到 “a+12” 这一段的数据已经被接收，接下来需要从 “a+1+12” 开始发送。
-
为了提升发送效率，也可以一次性发送多段数据，由接收方统一确认。
6.TCP的窗口滑动机制
TCP通过滑动窗口机制来控制数据的传输速率。
- 在TCP三次握手建立连接是，双方都会通过Window字段告诉对方本端最大能够接受的字节数（也就是缓冲区大小）。
- 连接建立成功之后，发送方会根据接收方宣告的Window大小发送相应字节数的数据。
- 接收方接收到数据之后会放在缓冲区内，等待上层应用来取走缓冲的数据。若数据被上层取走，则相应的缓冲空间将被释放。
- 接收方根据自身的缓存空间大小通告当前的可以接受的数据大小（Window）。
- 发送方根据接收方当前的Window大小发送相应数量的数据。
7.TCP的关闭 - 四次挥手
TCP支持全双工模式传输数据，这意味着同一时刻两个方向都可以进行数据的传输。在传输数据之前，TCP通过三次握手建立的实际上是两个方向的连接，因此在传输完毕后，两个方向的连接必须都关闭。如图所示：
- 由发起方发出一个FIN字段置 “1” 的不带数据的TCP段；
- 接收方收到发起方发来的FIN置位的TCP报文后，会回复一个ACK置位的TCP报文。
- 若接收方此时也没有了需要发送的数据，则直接发送FIN置位的TCP报文。假设此时接收方还有数据要发送，那么当PC2发送完这些数据之后会发送一个FIN置位的TCP报文去关闭连接。
- 发送方收到FIN置位的TCP报文，回复ACK报文，TCP双向连接断开。
8.关于TCP的一些问题
- 为什么需要三次握手？
- 首先我们要知道信道是不可靠的，但是我们要建立可靠的连接发送可靠的数据，也就是数据传输是需要可靠的。在这个时候三次握手是一个理论上的最小值，并不是说是tcp协议要求的，而是为了满足在不可靠的信道上传输可靠的数据所要求的。在《计算机网络》一书中其中有提到，三次握手的目的是“为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误”，这种情况是：发送方发出去的第一个连接请求报文并没有丢失，而是因为某些未知的原因在某个网络节点上发生滞留，导致延迟到连接释放以后的某个时间才到达接收方。本来这是一个早已失效的报文段，但是接收方收到此失效的报文之后，会误认为是发送方再次发出的一个新的连接请求，于是接收方就向发送方又发出确认报文，表示同意建立连接。如果不采用“三次握手”，那么只要接收方发出确认报文就会认为新的连接已经建立了，但是发送方并没有发出建立连接的请求，因此不会去向接收方发送数据，接收方没有收到数据就会一直等待，这样接收方就会白白浪费掉很多资源。如果采用“三次握手”的话就不会出现这种情况，接收方收到一个过时失效的报文段之后，向发送方发出确认，此时发送方并没有要求建立连接，所以就不会向接收方发送确认，这个时候接收方也能够知道连接没有建立。
- 为什么需要四次握手？
- 为了确保数据能够完成传输。关闭连接时，当接收方收到发送方的FIN报文通知时，它仅仅表示发送方没有数据发送给接收方了；但未必接收方所有的数据都全部发送给发送方了，所以接收方未必会马上会关闭连接,也即接收方可能还需要发送一些数据给发送方之后，再发送FIN报文给发送方来表示接收方同意现在可以关闭连接了，所以接收方这里的ACK报文和FIN报文多数情况下都是分开发送的。
- 释放连接时为什么TIME-WAIT状态必须等待2MSL时间？
- MSL（Maximum Segment Lifetime）：“报文最大生存时间”，即为任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
- 第一，为了保证发送方发送的最后一个ACK报文能够到达接收方。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的接收方收不到对已发送的FIN+ACK报文段的确认。接收方会超时重传这个FIN+ACK报文段，而发送方就能在2MSL时间内收到这个重传的FIN+ACK报文段，重置时间等待计时器（2MSL）。如果发送方在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到接收方重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，接收方就无法按照正常的步骤进入CLOSED状态。
- 第二，发送方在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。