TCP的三次握手与四次挥手
TCP的三次握手(建立连接）和四次挥手(关闭连接） https://www.cnblogs.com/Jessy/p/3535612.html
面试官，不要再问我三次握手和四次挥手https://juejin.cn/post/6844903958624878606 （这篇写得好）
三次握手和四次挥手过程中的异常处理https://blog.csdn.net/qq_34827674/article/details/119809480
三次握手时的初始化序列号是随机的，使用固定序列号不可以。https://blog.csdn.net/wangquan1992/article/details/97900840
TCP报文的结构
TCP报文由首部和数据两部分组成。首部一般由20-60字节（Byte）构成，长度可变。其中前20B格式固定，后40B为可选。
因为，TCP报文还得传给下层网络层，封装成IP包，而一个IP包最大长度为65535，同时IP包首部也包含最少20B，所以一个IP包或TCP包可以包含的数据部分最大长度为65535-20-20=65495B。
TCP报文中数据部分是可选的，即TCP报文可以不包含数据（同理IP包也可以不包含数据）。不含数据的TCP报文通常是一些确认和控制信息类的报文，如TCP建立连接时的三次握手和TCP终止时的四次挥手等。
1、源端口号（Source Port）
长度为16位，指明发送数据的进程。
2、目的端口号（Destination Port）
长度为16位，指明目的主机接收数据的进程。
3、序号（Sequence Number）
也称为序列号，长度为32位，序号用来标识从TCP发送端向接入端发送的数据字节流进行编号，可以理解成对字节流的计数。
4、确认号（Acknowledgement Number）
长度为32位，确认号包含发送确认的一端所期望收到的下一个序号。确认号只有在ACK标志为1时才有效。
5、首部长度
长度为4位，用于表示TCP报文首部的长度。用4位（bit）表示，十进制值就是[0,15]，一个TCP报文前20个字节是必有的，后40个字节根据情况可能有可能没有。如果TCP报文首部是20个字节，则该位应是20/4=5。
6、保留位（Reserved）
长度为6位，必须是0，它是为将来定义新用途保留的。
7、标志（Code Bits）
长度为6位，在TCP报文中不管是握手还是挥手还是传数据等，这6位标志都很重要。6位从左到右依次为：
URG：紧急标志位，说明紧急指针有效；
ACK：确认标志位，多数情况下空，说明确认序号有效；
PSH：推标志位，置位时表示接收方应立即请求将报文交给应用层；
RST：复位标志，用于重建一个已经混乱的连接；
SYN：同步标志，该标志仅在三次握手建立TCP连接时有效
FIN：结束标志，带该标志位的数据包用于结束一个TCP会话。
8、窗口大小（Window Size）
长度为16位，TCP流量控制由连接的每一端通过声明的窗口大小来提供。
9、检验和（Checksum）
长度为16位，该字段覆盖整个TCP报文端，是个强制性的字段，是由发送端计算和存储，到接收端后，由接收端进行验证。
10、紧急指针（Urgent Pointer）
长度为16位，指向数据中优先部分的最后一个字节，通知接收方紧急数据的长度，该字段在URG标志置位时有效。
11、选项（Options）
长度为0-40B（字节），必须以4B为单位变化，必要时可以填充0。通常包含：最长报文大小（MaximumSegment Size，MSS）、窗口扩大选项、时间戳选项、选择性确认（Selective ACKnowlegement，SACK）等。
12、数据
-----------------------------------
©著作权归作者所有：来自51CTO博客作者lyhbwwk的原创作品，请联系作者获取转载授权，否则将追究法律责任
TCP/IP 数据包报文格式（IP包、TCP报头、UDP报头）
https://blog.51cto.com/lyhbwwk/2162568
只需要知道这几点下图就能理解：
-
确认号（Acknowledgement Number）长度为32位，确认号包含发送确认的一端所期望收到的下一个序号。确认号只有在ACK=1时才有效，所以前两次握手ACK都置1。即下图中大写的SYN和ACK都是TCP数据报中的标志位标志（Code Bits）
- 小写的ack是确认号，包含发送确认的一端所期望收到的下一个序号。表明此序号的报文我已接收成功，期待收到下一个报文。
三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。
刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。 进行三次握手：
-
第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)。此时客户端处于
SYN_SEND状态。首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。
-
第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于
SYN_RCVD的状态。在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。
-
第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于
ESTABLISHED状态。服务器收到 ACK 报文之后，也处于ESTABLISHED状态，此时，双方已建立起了连接。确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。
链接：https://juejin.cn/post/6844903958624878606
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
下图中，SYN和ACK的置1都省略写了。途中表明的就是我发一个序列号，接收方回复一个序列号+1的确认号。
第二次握手丢失了，会发生什么？
当服务端收到客户端的第一次握手后，就会回 SYN-ACK 报文给客户端，这个就是第二次握手，此时服务端会进入 SYN_RCVD 状态。
第二次握手的 SYN-ACK 报文其实有两个目的 ：
- 第二次握手里的 ACK， 是对第一次握手的确认报文；
- 第二次握手里的 SYN，是服务端发起建立 TCP 连接的报文；
所以，如果第二次握手丢了，就会发送比较有意思的事情，具体会怎么样呢？
因为第二次握手报文里是包含对客户端的第一次握手的 ACK 确认报文，所以，如果客户端迟迟没有收到第二次握手，那么客户端就觉得可能自己的 SYN 报文（第一次握手）丢失了，于是客户端就会触发超时重传机制，重传 SYN 报文。
然后，因为第二次握手中包含服务端的 SYN 报文，所以当客户端收到后，需要给服务端发送 ACK 确认报文（第三次握手），服务端才会认为该 SYN 报文被客户端收到了。
那么，如果第二次握手丢失了，服务端就收不到第三次握手，于是服务端这边会触发超时重传机制，重传 SYN-ACK 报文。
在 Linux 下，SYN-ACK 报文的最大重传次数由 tcp_synack_retries 内核参数决定，默认值是 5。
因此，当第二次握手丢失了，客户端和服务端都会重传：
- 客户端会重传 SYN 报文，也就是第一次握手，最大重传次数由 tcp_syn_retries 内核参数决定。；
- 服务端会重传 SYN-AKC 报文，也就是第二次握手，最大重传次数由 tcp_synack_retries 内核参数决定。
————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
原文链接：https://blog.csdn.net/qq_34827674/article/details/119809480
三次握手可以总结为：
- SYN
- SYN+ACK
- ACK
