背景我和女朋友异地恋一年多了。为了维持关系，我提议每晚视频一次。从开始，到现在，一年多的时间也算是坚持了。问题有时候在聊天的时候，可能我的网络或者她的网络不好，视频会卡顿，听不到对方的声音，过一会就恢复了。中间的两方可能要不断确认网络是否恢复，但有时：她：“Canyouhearme?”我：“好的，你呢？”，她：“嘿，你能听到我说话吗？”我：“好的，我能听到，你呢？”她：“你能听到吗？”……这种情况很痛苦，那么如何才能找到一个简单的方法让两个人互相倾听呢？你确定你能听到对方的声音，对方也能听到你自己的声音吗？注：以下情节纯属虚构。为什么TCP建立连接时采用三次握手而不是两次或四次？TCP，全称TransmissionControlProtocol，是一种可靠的传输层协议，IP协议号为6。顺便说一下，原则上任何数据传输都不能保证绝对可靠，三次握手只是基本的需要保证可靠性。举一个日常的例子，当我们打电话的时候，我们的对话是这样的：对应客户端和服务端的通信：所以我们有下面的对话：我：1+1等于多少？她：2,2+2等于多少？我：4.首先，两个人达成协议。1.当网络情况不对时，任何一方都可以发起查询。2、任何情况下，如果发起查询后5秒内没有收到回复，则认为网络不可用。3.网络不可用。等待1分钟，然后再开始询问。对我来说，发起“1+1等于多少”的查询后，1.如果5秒内没有收到回复，就认为网络不通。2.如果收到回复，我确认①我能听到她的消息②她能听到我的消息，然后回复她的问题。对于她来说，当她觉得网络情况不对时1.如果没有收到我的询问，她会发起询问2.如果她收到“1+1等于什么”，她确认①她能听到我的消息,然后回复我的问题和她的问题的答案“2,2+2等于什么”3.如果5s内没有收到当我得到我的回复“4”时，她确认②我听不到她的声音消息4.如果在5秒内收到我的回复“4”，她确认②我可以听到她的消息。这样，如果以上对话完成，就证明双方可以确认可以听到对方的声音，而对方也可以听到自己的声音！这个故事能解释一下为什么TCP需要三次握手吗...囧大概四次挥手，客户端发送一个FIN给服务端，请求关闭数据传输。服务器收到客户端的FIN后，向客户端发送ACK，ack的值等于FIN+SEQ。服务器然后向客户端发送一个FIN，告诉客户端应用程序关闭。当客户端从服务器收到FIN时，它向服务器回复一个ACK??。ack的值等于FIN+SEQ。为什么要挥手4次？确保数据可以完整传输。当被动方收到主动方的FIN报文通知时，仅表示主动方没有数据可以发送给被动方。但不一定被动方的所有数据都已经完全发送给主动方，所以被动方不会立即关闭SOCKET，它可能还需要发送一些数据给主动方，然后发送一个FIN报文给主动方主动方告诉主动方同意关闭连接，所以这里的ACK报文和FIN报文大多数情况下是分开发送的。1.TCP报文格式TCP报文格式图：上图中有几个字段需要强调一下：(1)Sequencenumber：Seq序号，占用32位，用于标识从TCP源发送到目的端的字节destinationStream，发起者发送数据时标记。(2)Acknowledgementsequencenumber：Ack序列号，占用32比特，只有当ACK标志为1时，确认序列号字段才有效，Ack=Seq+1。(3)标志位：共6位，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：(A)URG：紧急指针(urgentpointer)有效。(B)ACK：确认序列号有效。(C)PSH：接收方应尽快将此消息传递给应用层。(D)RST：重置连接。(E)SYN：发起一个新的连接。(F)FIN：释放一个连接。注意：（A）不要将确认号Ack和flag中的ACK混淆。(B)确认方Ack=发起方Req+1，两端配对。2.三次握手TCP（TransmissionControlProtocol） TransmissionControlProtocolTCP是一种主机到主机层的传输控制协议，提供可靠的连接服务。它使用三次握手来确认一个连接的建立位码，即tcpflag。Mark有6种：SYN（同步连接建立）ACK（确认确认）PSH（推送传输）FIN（finish结束）RST（reset重置）URG（urgent紧急）Sequencenumber（序列号）Acknowledgenumber（确认号）建立,create所谓三向握手（Three-WayHandshake）就是建立一个TCP连接，也就是说建立一个TCP连接时，客户端和服务器一共需要发送3个数据包来确认建立的连接。在socket编程中，这个过程是由客户端执行connect触发的，整个过程如下图所示：(1)第一次握手：客户端将标志位SYN置1，随机产生一个值seq=J，并发送数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。(2)第二次握手：服务器收到数据包后，知道客户端请求建立连接，标志位SYN=1，服务器将标志位SYN和ACK都设置为1，ack(number)=J+1，并随机生成一个值seq=K，并发送数据包给Client确认连接请求，Server进入SYN_RCVD状态。(3)第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确，标志位ACK置1，ack=K+1，并且数据包发送给服务端，服务端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端与服务端进入ESTABLISHED状态，完成三项方式握手，然后客户端和服务器就可以开始传输数据了。SYN攻击：在三次握手过程中，Server发送SYN-ACK后，在收到Client的ACK之前的TCP连接称为半开连接。此时Server处于SYN_RCVD状态。Server收到ACK后，进入ESTABLISHED状态。SYN攻击是Client在短时间内伪造大量不存在的IP地址，不断向Server发送SYN包，Server回复确认包，等待Client的确认。这些虚假的SYN包会长期占据未连接的队列，导致正常的SYN请求因为队列满而被丢弃，造成网络拥塞甚至系统故障。SYN攻击是典型的DDOS攻击。检测SYN攻击的方法非常简单。即当服务器上存在大量的半连接状态且源IP地址是随机的时，可以断定是受到了SYN攻击。使用如下命令使其为Current：#netstat-nap|grepSYN_RECV三四次挥手三次握手很熟悉，四次挥手估计就是..所谓四次挥手（Four-WayWavehand）终止TCP连接，也就是说当断开一个TCP连接时，client端需要和server端一共发送4个数据包来确认连接的断开。在套接字编程中，这个过程是由客户端或服务器执行关闭触发的。整个过程如下图所示：由于TCP连接是全双工的，所以每个方向都要单独关闭。一个原则是，当一方完成发送数据的任务后，发送一个FIN终止这个方向的连接。收到一个FIN只是意味着这个方向没有数据流，即不会再收到数据，但是在这个TCP连接上仍然可以发送数据，直到那个方向也发送了一个FIN。先关闭的一侧将执行主动关闭，而另一侧将执行被动关闭，如上图所示。(1)第一次挥手：Client发送FIN关闭Client到Server的数据传输，Client进入FIN_WAIT_1状态。(2)第二次挥手：Server收到FIN后，向Client发送ACK，确认序号为收到的序号+1（同SYN，1个FIN占1个序号），Server进入CLOSE_WAIT状态。(3)第三次挥手：服务器发送一个FIN，关闭服务器向客户端的数据传输，服务器进入LAST_ACK状态。(4)第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，然后向Server发送ACK，确认序号为收到的序号+1，Server进入CLOSED状态，并完成四次挥手。以上是一方主动关机，另一方被动关机的情况。实践中也会出现同时发起主动关机的情况。具体流程如下：流程和状态在上图中已经很清楚了，这里不再赘述。可以参考前面的四波解析步骤。4.注意事项三向握手和四向握手一般都有典型的面试题。下面给一些需要的XDJM们参考一下：（1）什么是三次握手或者流程？四次握手呢？答案是前面的分析。(2)为什么建立连接是三次握手，而关闭连接是四次握手？这是因为服务器在LISTEN状态下收到连接建立请求的SYN报文后，将ACK和SYN合二为一发送给客户端。关闭连接时，当收到对方的FIN报文时，只代表对方不再发送数据但还能接收数据，而己方可能还没有将所有数据发送给对方，所以己方可以立即关闭，或者发送一些数据给对方后，发送FIN报文给对方表示同意现在关闭连接。所以自己的ACK和FIN一般是分开发送的。
