什么是三次握手三次握手是指在建立TCP连接时客户端和服务端总共会发送三个数据包。只有三个数据包都发送成功后TCP连接才会建立成功。否则丢失任何一个包都会导致连接建立失败。发送三个数据包的过程被人形象的称为三次握手。三次握手过程如图是我找到的三次握手示意图通常在socket编程中服务端会绑定端口然后调用listen接口挂起等待。而客户端会绑定服务端的IP和端口然后调用connect接口发起连接。连接成功后双方便会相互发送消息。其实这个过程就是TCP建立连接的过程也就是三次握手过程。只是底层原理和过程全部封装在内核层面上用户编程时无需感知和亲自操作。那现在就详细说下这个建立连接的过程。首先第一次握手时客户端会发送一个报文其中标志位SYN1其余为0。表示这是一个请求建立连接的报文。同时客户端还会生成一个随机数x当作序列号即seqx也称之为初始序列号。后续的序号确认、超时重传、重复丢弃等等都会基于这个初始序列号去做。所以这个初始序列号很关键。前面我们知道序列号seq占4个字节所以x的范围也就是[0,4294967295]。服务端收到这个报文后通过SYN1便可以知道这是一个请求建立连接的报文。如果此时服务端已经准备好同意建立连接。那么它便会回复一个确认报文即ACK1ackx1。注意普通报文中ACK为0确认报文中ACK一定为1。那ack为啥是x1呢首先我们要明白大写的ACK是标志位小写的ack是确认号。确认号就是用来回复对方的告诉对方我接收了多少数据下次你应该从哪里发送参考上一章节。那为啥是x1而不是x100或1000呢这里就要说下ack的计算逻辑了。如果发送方发送的序号是x携带数据长度是n。如果接收方全部接收成功则返回的ack就是xn。这样我们只需要知道建立连接时携带数据长度是多少就行了。答案是三次握手中三个包均没有携带任何数据即数据长度为0。那为啥不是x0呢答案是TCP协议约定SYN1的报文段不能携带数据但要消耗掉一个序号。FIN报文同样如此即使不携带数据也要消耗一个序号。所以确认号就是x1即ackx1。tcp是全双工的就是双方都能收发数据。那客户端到服务端的连接通了后服务端肯定也要向客户端发起请求建立连接。过程和客户端发起时一模一样就是发送一个报文其中SYN1序号seqy。聪明的你立马会想到到这里服务端已经发送了两个报文一个是确认报文ACK1一个是请求建立连接报文SYN1。这和上面只发送一条报文显然是不一样的。为什么呢答案是TCP协议做了优化将两条报文合并成一个报文了。就是服务端只发送一条报文SYN1SCK1seqyackx1既表示确认报文又表示请求建立连接报文。这在TCP中被称为“捎带应答”。这个全部过程也被称为二次握手。这里也说明为啥建立连接时候最少需要3次握手其实4次更标准但效率低没必要。客户端收到服务端的SYN1报文后立即回复一个确认报文ACK1seqx1acky1。此时的确认号ack的计算逻辑和上面一样所以是y1。这个过程被称为第三次握手。下面我同时用抓包的报文数据来验证这个过程。图如下前三行就是三次握手中的三个包。第一次握手客户端-服务端SYN1seq0。第二次握手服务端-客户端SYN1ACK1seq0ack1。第三次握手客户端-服务端ACK1seq1ack1。注意此处的两个初始序列号都是0这里的0是相对值只是展示方便。实际传输的都是真实值一般比较大。后面讲解抓包的报文时再详细说明。三次握手结束后连接正式建立成功双方便可以相互发送数据了。三次握手中同步哪些信息上面示意图简化了建立连接的过程。从上面我们知道建立TCP连接时候双方会互相同步自己的初始序列号后续的确认号都是基于这个而来。那除了这个外还同步哪些信息呢从上面抓包的报文中还可以看到有winMSSSACK_PERM以及时间戳等。其中win表示窗口大小后面每个报文中也都会携带上用来告知对方我的剩余缓冲区空间还有多大你下次还能发多少。这个不是只在建立连接时候才有每次收发报文都会带上故先忽略。而MSS和SACK这两个是明确只在建立连接时候才有其余报文中不会携带。上一章节说过MSS的出现是为了解决TCP包过大而导致被分片。而MSS又依赖网卡的MTUMTU越大单包携带的有效数据便越多。那如果双方机器性能不一样怎么办呢举例如果客户端MTU2000服务端MTU1500。TCP/IP包头都是按最小情况算下同在不交换信息情况下客户端的MSS最大便可以达到2000-20-201960而服务端的MSS最大是1500-20-201460。如果此时客户端发送TCP包携带数据长度是1800字节不超过1960正常数据包则到达网络层后IP包大小为180020201920字节。虽然19202000在客户端网络上不会被分片但到达服务端时还是会因为超过了1500在服务端上被分片。依旧会造成丢包等问题。所以TCP建立连接时需要协商一个双方都支持的最小MSS也就是取客户端和服务端两个中最小的那个MSS。这也是为啥必须在建立连接时候同步MSS的原因。MSS一旦确定后不在改变所有后续包不会再携带这个信息。同理SACK也是这个原因才会出现在首次建立连接中。只有双方都支持SACK才行。仔细点会发现连接建立时候发送的是SACK_PERM全称是SACK-Permitted。表示是否允许开启SACK这个选项功能不允许就算了允许后后续报文头的选项中可能会出现SACK的内容。就是批量发送报文中哪些区间丢失了在SACK中体现。后面只需要针对性重传这些丢失的区间就行不用全部都传输提高了效率。所以让我们总结下三次握手时会同步哪些信息初始序列号、MSS、SACK、时间戳等。为什么不能两次握手首先从理论上分析为啥不能两次握手就可以建立连接。TCP传输是可靠的是全双工的。双方都需要知道自己的发送和接收是否正常。如果是两次握手即A发送信息给BB接收到后返回消息给A。到这里A是能够确认自己的发送和接收是没问题的但B只能确认自己的接收没有问题无法确认自己的发送是否正常。只有A给B回消息后B收到了才能确认自己的发送也没问题。所以从理论上讲要想确认双方收发是否都正常两次报文交互是做不到的至少三次。另外也可以从实现上面来分析下两次握手会有哪些危害。先说结论两次握手会导致两个问题1.造成服务端资源浪费、产生大量无效连接。2.影响新的连接可能会引起脏数据或中断当前新连接。是想下如果两次握手即可成功建立连接。那么如果某一次的SYN报文超时了那客户端会重新发送一次SYN报文服务端正常接收后建立连接。但过了一会刚才超时的SYN报文又到达服务端了服务端又会创建一个连接。这样一来就产生了两个连接。如果多个客户端多次超时后就会产生很多个无效连接。服务端创建连接的本质就是分配缓存占用端口资源。这样就造成了服务端资源浪费。那为什么三次握手不会有这种情况呢。同样的过程超时SYN重新到达服务端后服务端还是会分配缓存占用端口。但此时服务端给客户端回复消息后客户端判断连接已经建立成功了。这次的SYN不是新的而是旧报文延迟了直接丢掉就行。客户端便会返回一个RST给客户端告诉对方把刚才创建的多余缓存都释放了吧。这样就不存在资源浪费了。至于第二种情况产生的原因则更为复杂。如果旧连接断开后客户端又立马发起一次新的连接。且端口被快速复用双方四元组和之前一模一样。那么如果此时有一个滞留很久的旧包过来了接收方如何处理呢1.如果旧包的序列号或会话等信息完全超出新连接的窗口范围接收方便认定这个包不属于当前连接。是一个旧的非法数据它会直接丢弃这个数据并立刻发送RST给对方。刚建立的正常新连接直接被强制断开。2.果旧包的序列号或会话等信息在新连接的窗口范围。内核会认为这个包是正常的不丢弃按正常数据处理。此时读取出来的数据就是脏数据。建立连接时出现问题怎么办重传机制是怎样的如何判断是同一个链接