简述三次握手和四次挥手过程(三次握手和四次挥手详细介绍)

要了解三次握手&四次挥手的过程，就需要对TCP的报头以及有限状态机的概念有所了解，本文将介绍TCP报头的字段的含义，以及有限状态机各个状态的意义，最后对三次握手和四次挥手的过程做介绍 TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议（UDP）是同一层内另一个重要的传输协议。在因特网协议族（Internet protocol suite）中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。这里将介绍TCP报头的特性以及TCP报头各个字段的含义.工作在传输层面向连接协议.全双工协议.半关闭.错误检查.将数据打包成段，排序.确认机制.数据恢复，重传.流量控制，滑动窗口.拥塞控制，慢启动和拥塞避免算法.源端口、目标端口 ：计算机上的进程要和其他进程通信是要通过计算机端口的，而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的，可推算计算机的端口个数为2^16个. 序列号 ：表示本报文段所发送数据的第一个字节的编号。在TCP连接中所传送的字节流的每一个字节都会按顺序编号。由于序列号由32位表示，所以每2^32个字节，就会出现序列号回绕，再次从0 开始. 确认号 ：表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。也就是告诉发送发：我希望你（指发送方）下次发送的数据的第一个字节数据的编号是这个确认号. 数据偏移 ：表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可变的选项部分，需要指定这个TCP报文段到底有多长。它指出TCP 报文段的数据起始处距离TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节. URG ：表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段（urgent pointer）只有当URG=1时才有效. ACK ：表示是否前面的确认号字段是否有效。ACK=1，表示有效。只有当ACK=1时，前面的确认号字段才有效。TCP规定，连接建立后，ACK必须为1,带ACK标志的TCP报文段称为确认报文段. PSH ：提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间。如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序不将接收到的数据读走，就会一直停留在TCP接收缓冲区中. RST ：如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST标志的TCP报文段称为复位报文段. SYN ：在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段. FIN ：表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段. 窗口大小 ：表示现在充许对方发送的数据量，也就是告诉对方，从本报文段的确认号开始允许对方发送的数据量. 校验和 ：提供额外的可靠性. 紧急指针 ：标记紧急数据在数据字段中的位置. 选项部分 ：其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：(2^4-1)*4-20=40字节常见选项 ：.最大报文段长度：MaxiumSegment Size，MSS.窗口扩大：Windows Scaling.时间戳：Timestamps.a 最大报文段长度指明自己期望对方发送TCP报文段时那个数据字段的长度。默认是536字节。数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS不宜设的太大也不宜设的太小。若选择太小，极端情况下，TCP报文段只含有1字节数据，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，网络的利用率就不会超过1/41。若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传，这些也都会使开销增大。因此MSS应尽可能大，只要在IP层传输时不需要再分片就行。在连接建立过程中，双方都把自己能够支持的MSS接入这一字段。MSS只出现在SYN报文中。即：MSS出现在SYN=1的报文段中.b 窗口扩大为了扩大窗口，由于TCP首部的窗口大小字段长度是16位，所以其表示的最大数是65535。但是随着时延和带宽比较大的通信产生（如卫星通信），需要更大的窗口来满足性能和吞吐率，所以产生了这个窗口扩大选项.c 时间戳可以用来计算RTT(往返时间)，发送方发送TCP报文时，把当前的时间值放入时间戳字段，接收方收到后发送确认报文时，把这个时间戳字段的值复制到确认报文中，当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS，也可以说可以用来区分相同序列号的不同报文。因为序列号用32为表示，每2^32个序列号就会产生回绕，那么使用时间戳字段就很容易区分相同序列号的不同报文2.3 TCP协议PORT.传输层通过port号，确定应用层协议.Port number:. tcp ：0-65535,传输控制协议，面向连接的协议；通信前需要建立虚拟链路；结束后拆除链路.. udp ：0-65535,User Datagram Protocol，无连接的协议.. IANA :互联网数字分配机构（负责域名，数字资源，协议分配）0-1023：系统端口或特权端口(仅管理员可用) ，众所周知，永久的分配给固定的系统应用使用，22/tcp(ssh), 80/tcp(http), 443/tcp(https)1024-49151：用户端口或注册端口，但要求并不严格，分配给程序注册为某应用使用，1433/tcp(SqlServer)，1521/tcp(oracle),3306/tcp(mysql),11211/tcp/udp(memcached)49152-65535：动态端口或私有端口，客户端程序随机使用的端口其范围的定义：/proc/sys/net/ipv4/ip_local_port_range有限状态机，（英语：Finite-state machine, FSM），又称有限状态自动机，简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。常见的计算机就是使用有限状态机作为计算模型的：对于内存的不同状态，CPU通过读取内存值进行计算，更新内存中的状态。CPU还通过消息总线接受外部输入设备（如键盘、鼠标）的指令，计算后更改内存中的状态，计算结果输出到外部显示设备（如显示器），以及持久化存储在硬盘。TCP协议也存在有限状态机的概念，TCP 协议的操作可以使用一个具有 11 种状态的有限状态机来表示.CLOSED 没有任何连接状态.LISTEN 侦听状态，等待来自远方TCP端口的连接请求.SYN-SENT 在发送连接请求后，等待对方确认.SYN-RECEIVED 在收到和发送一个连接请求后，等待对方确认.ESTABLISHED 代表传输连接建立，双方进入数据传送状态.FIN-WAIT-1 主动关闭,主机已发送关闭连接请求，等待对方确认.FIN-WAIT-2 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求.TIME-WAIT 完成双向传输连接关闭，等待所有分组消失.CLOSE-WAIT 被动关闭,收到对方发来的关闭连接请求，并已确认.LAST-ACK 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失.CLOSING 双方同时尝试关闭传输连接，等待对方确认.客户端通过connect系统调用主动与服务器建立连接connect系统调用首先给服务器发送一个同步报文段，使连接转移到SYN_SENT状态。.此后connect系统调用可能因为如下两个原因失败返回：.1、如果connect连接的目标端口不存在（未被任何进程监听），或者该端口仍被处于TIME_WAIT状态的连接所占用（见后文），则服务器将给客户端发送一个复位报文段，connect调用失败。.2、如果目标端口存在，但connect在超时时间内未收到服务器的确认报文段，则connect调用失败。.connect调用失败将使连接立即返回到初始的CLOSED状态。如果客户端成功收到服务器的同步报文段和确认，则connect调用成功返回，连接转移至ESTABLISHED状态.当客户端执行主动关闭时，它将向服务器发送一个结束报文段FIN，同时连接进入FIN_WAIT_1状态。若此时客户端收到服务器专门用于确认目的的确认报文段，则连接转移至FIN_WAIT_2状态。当客户端处于FIN_WAIT_2状态时，服务器处于CLOSE_WAIT状态，这一对状态是可能发生半关闭的状态。此时如果服务器也关闭连接（发送结束报文段），则客户端将给予确认并进入TIME_WAIT状态.客户端从FIN_WAIT_1状态可能直接进入TIME_WAIT状态（不经过FIN_WAIT_2状态），前提是处于FIN_WAIT_1状态的服务器直接收到带确认信息的结束报文段（而不是先收到确认报文段，再收到结束报文段）注意，客户端先发送一个FIN给服务端，自己进入了FIN_WAIT_1状态，这时等待接收服务端的报文，该报文会有三种可能：a 只有服务端的ACK，只收到服务器的ACK，客户端会进入FIN_WAIT_2状态，后续当收到服务端的FIN时，回应发送一个ACK，会进入到TIME_WAIT状态，这个状态会持续2MSL(TCP报文段在网络中的最大生存时间,RFC 1122标准的建议值是2min).客户端等待2MSL，是为了当最后一个ACK丢失时，可以再发送一次。因为服务端在等待超时后会再发送一个FIN给客户端，进而客户端知道ACK已丢失b 只有服务端的FIN，回应一个ACK给服务端，进入CLOSING状态，然后接收到服务端的ACK时，进入TIME_WAIT状态c 同时收到服务端的ACK和FIN，直接进入TIME_WAIT状态.收到服务器ACK后，客户端处于FIN_WAIT_2状态，此时需要等待服务器发送结束报文段，才能转移至TIME_WAIT状态，否则它将一直停留在这个状态。如果不是为了在半关闭状态下继续接收数据，连接长时间地停留在FIN_WAIT_2状态并无益处。连接停留在FIN_WAIT_2状态的情况可能发生在：客户端执行半关闭后，未等服务器关闭连接就强行退出了。此时客户端连接由内核来接管，可称之为孤儿连接（和孤儿进程类似）。.Linux为了防止孤儿连接长时间存留在内核中，定义了两个内核参数：./proc/sys/net/ipv4/tcp_max_orphans 指定内核能接管的孤儿连接数目./proc/sys/net/ipv4/tcp_fin_timeout指定孤儿连接在内核中生存的时间TCP协议中的三次握手和四次挥手客户机端的三次握手和四次挥手服务器端的三次握手和四次挥手1 client 首先发送一个连接试探，此时ACK=0,表示确认号无效，SYN=1表示这是一个请求连接或连接接受报文，同时表示这个数据包不携带数据，seq=x表示此时client自己数据的初始序号是x,这时候client进入syn_sent状态，表示客户端等等服务器的回复2 server 监听到连接请求报文后，如同意建立连接，则向client发送确认，将TCP报文首部的SYN和ACK都置为1，因为client上一个请求连接的报文中seq=x,所以服务器端这次就发ack=x+1,表示服务器端希望客户端下一个报文段的第一个数据字节序号是x+1，同时表示x为止的所有数据都已经正确收到了，其中，此时服务器端发送seq=y表示server自己的初始序号是y，这时服务器进入了SYN_RCVD状态，表示服务器已经收到了客户端的请求，等待client的确认。3 client收到确认后还要再次给服务器端发送确认，同时携带要发给server的数据。ACK=1表示确认号ack=y+1有效，client这时的序号seq为x+1一旦client确认后，这个TCP连接的client 和 server 都直接进入到established状态，可以发起http请求了4.2 四次挥手详解第一次挥手：client向server，发送FIN报文段，表示关闭数据传送，此时ACK=0,seq=u,表示客户端此时数据的报文序号是u，此时，client进入FIN_WAIT_1状态，表示没有数据要传输了第二次挥手：server收到FIN报文段后进入CLOSE_WAIT状态（被动关闭），然后发送ACK确认，表示同意你关闭请求了，主机到主机的数据链路关闭，同时发送seq=v,表示此时server端的数据包字节序号是v,ack=u+1,表示希望client发送的下一个包的序号是u+1,表示确认了序号u之前的包都已经收到，客户端收到server的ACK报文后，进入FIN_WAIT_2状态第三次挥手：server等待client发送完数据，发送FIN=1，ACK=1到client请求关闭，server进入LAST_ACK状态。此时发送的seq有变化，因为上一个ACK的后server端可能又发送了一些数据，说以数据字节序号发送了变化，为w,但是ack还是保持不变第四次挥手：client收到server发送的FIN后，回复ACK确认到server，client进入TIME_WAIT状态。发送ack=w+1,表示希望服务器下个发送的报文的字节序号是w+1,确认了服务器之前发送的w字节都已经正确收到，发送seq=u+1表示当前client的字节序号是u+1.server收到client的ACK后就关闭连接了，状态为CLOSED。client等待2MSL，仍然没有收到server的回复，说明server已经正常关闭了，client关闭连接。其中，MSL（Maximum Segment Lifetime）：报文最大生存时间，是任何报文段被丢弃前在网络内的最长时间。当client回复server的FIN后，等待(2-4分钟)，即使两端的应用程序结束。TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态的原因是如果client直接进入CLOSED状态，由于IP协议不可靠性或网络问题，导致client最后发出的ACK报文未被server接收到，那么server在超时后继续向client重新发送FIN，而client已经关闭，那么找不到向client发送FIN的连接，server这时收到RST并把错误报告给高层，不符合TCP协议的可靠性特点。如果client直接进入CLOSED状态，而server还有数据滞留在网络中，当有一个新连接的端口和原来server的相同，那么当原来滞留的数据到达后，client认为这些数据是新连接的。等待2MSL确保本次连接所有数据消失。 当客户端等待2MSL后服务器端没有再次发送确认的报文后，client认为该次断开连接已经正常结束，client进入closed状态。四次挥手正式结束

为什么要三次握手 三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常所以三次握手就能确认双发收发功能都正常，缺一不可。 第四次握手：任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。
只知道三次握手，A向B发送信息，B会向A返回一个收到确认的消息，A还会对这个确认消息发送一次再确认，所以一个消息要经过三次的消息交互才算发送完成，这就是三次握手

TCP的三次握手和四次挥手实质就是TCP通信的连接和断开。 三次握手：为了对每次发送的数据量进行跟踪与协商，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系，并建立虚连接。四次挥手：即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。TCP三次握手、四次挥手时序图TCP协议位于传输层，作用是提供可靠的字节流服务，为了准确无误地将数据送达目的地，TCP协议采纳三次握手策略。三次握手原理：第1次握手：客户端发送一个带有SYN（synchronize）标志的数据包给服务端；第2次握手：服务端接收成功后，回传一个带有SYN/ACK标志的数据包传递确认信息，表示我收到了；第3次握手：客户端再回传一个带有ACK标志的数据包，表示我知道了，握手结束。其中：SYN标志位数置1，表示建立TCP连接；ACK标志表示验证字段。可通过以下趣味图解理解三次握手：三次握手过程详细说明：1、客户端发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的，并且将报文中的SYN字段置为1，表示需要建立TCP连接。（SYN=1，seq=x，x为随机生成数值）；2、服务端回复客户端发送的TCP连接请求报文，其中包含seq序列号，是由回复端随机生成的，并且将SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。（SYN=1，ACK=x+1，seq=y，y为随机生成数值）这里的ack加1可以理解为是确认和谁建立连接；3、客户端收到服务端发送的TCP建立验证请求后，会使自己的序列号加1表示，并且再次回复ACK验证请求，在服务端发过来的seq上加1进行回复。（SYN=1，ACK=y+1，seq=x+1）。由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。四次挥手原理：第1次挥手：客户端发送一个FIN，用来关闭客户端到服务端的数据传送，客户端进入FIN_WAIT_1状态；第2次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态；第3次挥手：服务端发送一个FIN，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态；第4次挥手：客户端收到FIN后，客户端t进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。其中：FIN标志位数置1，表示断开TCP连接。可通过以下趣味图解理解四次挥手：四次挥手过程详细说明：1、客户端发送断开TCP连接请求的报文，其中报文中包含seq序列号，是由发送端随机生成的，并且还将报文中的FIN字段置为1，表示需要断开TCP连接。（FIN=1，seq=x，x由客户端随机生成）；2、服务端会回复客户端发送的TCP断开请求报文，其包含seq序列号，是由回复端随机生成的，而且会产生ACK字段，ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP断开请求已经得到验证。（FIN=1，ACK=x+1，seq=y，y由服务端随机生成）；3、服务端在回复完客户端的TCP断开请求后，不会马上进行TCP连接的断开，服务端会先确保断开前，所有传输到A的数据是否已经传输完毕，一旦确认传输数据完毕，就会将回复报文的FIN字段置1，并且产生随机seq序列号。（FIN=1，ACK=x+1，seq=z，z由服务端随机生成）；4、客户端收到服务端的TCP断开请求后，会回复服务端的断开请求，包含随机生成的seq字段和ACK字段，ACK字段会在服务端的TCP断开请求的seq基础上加1，从而完成服务端请求的验证回复。（FIN=1，ACK=z+1，seq=h，h为客户端随机生成）至此TCP断开的4次挥手过程完毕。LISTEN：等待从任何远端TCP 和端口的连接请求。SYN_SENT：发送完一个连接请求后等待一个匹配的连接请求。SYN_RECEIVED：发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。ESTABLISHED：表示一个打开的连接，接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。FIN_WAIT_1：等待远端TCP 的连接终止请求，或者等待之前发送的连接终止请求的确认。FIN_WAIT_2：等待远端TCP 的连接终止请求。CLOSE_WAIT：等待本地用户的连接终止请求。CLOSING：等待远端TCP 的连接终止请求确认。LAST_ACK：等待先前发送给远端TCP 的连接终止请求的确认（包括它字节的连接终止请求的确认）TIME_WAIT：等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。TIME_WAIT 两个存在的理由：1.可靠的实现tcp全双工连接的终止；2.允许老的重复分节在网络中消逝。 CLOSED：不在连接状态（这是为方便描述假想的状态，实际不存在）。

下面的是引用的，大家共同学习，呵呵~~ TCP握手协议在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：未连接队列：在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。Backlog参数：表示未连接队列的最大容纳数目。SYN-ACK 重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。 半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。
你说呢...
三次握手： 第一次握手：客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。四次挥手与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。 第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

TCP/IP 传输协议的 TCP 协议是面向连接的，也就是传输数据之前，必须建立可靠的连接。建立连接的过程中，需交换信息（如选取哪种协议、协议版本等），这个过程称为 握手 handshaking 。 握手过程中会协商后续通信使用的参数，如传输速率、编码方式、校验，以及其他协议选取、硬件支持的功能等。握手是两个实体之间的通信，但在 TCP/IP 中握手常指 TCP 的三次握手。TCP 中的数据传输、连接建立与终止都由特定控制参数管理，控制参数有以下这些：建立 TCP 连接需要三次握手：TCP 连接的双方通过三次握手确定 TCP 连接的初始序列号、窗口大小以及最大数据段，这样通信双方就能利用连接中的初始序列号保证双方数据段的不重不漏，通过窗口大小控制流量，并使用最大数据段避免 IP 协议对数据包分片。换个角度看为什么需要三次握手？客户端和服务端通信前要进行连接，三次握手就是为了确保自己和对方的收发能力是正常的。三次握手后，客户端、服务端才确认了自己的接收、发送能力均是正常的。HTTP 协议中的数据是明文传输的，任何中间人（man-in-the-middle）都可以读取传输的数据，因此 HTTP 是一种不安全的协议。HTTPS 是 HyperText Transfer Protocol Secure 的缩写。但 HTTPS 协议自身不能加密数据，它需要借助 SSL 或 TLS 协议层进行加密。HTTP 协议和 TLS 协议都位于 application layer。TCP 三次握手建立连接后，使用 TLS 握手建立安全连接，后续使用协商的加密算法先对数据进行加密，再通过 HTTP 传输。数据加密后，中间人即使获得了数据，也无法读取数据内容，进而避免了中间人攻击（man-in-the-middle-attack）。HTTP 协议和 TLS 协议一起使用时，称为 HTTPS 协议。App 想要使用 TLS 加密通信，只需网址使用 https:// 前缀即可。要了解 TLS 工作原理，需先了解加密的工作原理，以及各种加密算法。加密就是将数据从一种格式编码为另一种格式，编码时使用一些数学算法、秘密参数。使用相同算法、参数，可以解密数据，这个过程中的参数称为密钥（key）。非对称加密算法有两个 key：最流行的非对称加密算法是 RSA 加密算法，广泛用于密钥交换和数字签名验证。但现在正逐步迁移至更安全高效的 Diffie-Hellman （缩写为 D-H）算法。非对称加密算法通常速度慢，更耗费 CPU，且 key、数据越长，加密、解密耗费时间也越长。因此，数据量大时不要使用非对称加密，而应使用对称加密（symmetric key cryptography），对称加密速度更快、性能更高。非对称加密用于传输对称加密密钥。对称加密算法也称为共享密钥加密（shared key），它使用相同的 key 加密、解密。对称加密算法主要用于受信任两者之间建立加密通道。因为第三方无法获取对称密钥，因此只有建立通道的双方才可以解密数据。最流行的对称加密算法是 AES（Advanced Encryption Standard 的缩写，即高级加密标准），SSL 协议由 Netscape 团队设计，于1995年发布 SSL 2.0版本，之后发布了 SSL 3.0版本，IETF 已于2015年不推荐使用 SSL 3.0。目前，TLS 协议已经替代了 SSL 协议，SSL 协议已不再使用。TLS 是旨在提供安全通信的加密协议，使用 TLS 可以加密与服务器的所有通信。当前使用最广的是 TLS 1.2、TLS 1.3。TLS 1.3 发布于2018年，是对 TLS 1.2 的全面修订，在性能和安全性方面都有很大提升，并且减少了建立安全连接所需的握手次数。TLS 1.3 只支持 Diffie-Hellman 非对称加密算法，移除了 RSA 算法。使用 HTTPS 发送 HTTP 请求时，首先使用三次握手建立可靠的 TCP 连接，之后就通过 TLS 四次握手交换双方的密钥。下面介绍 TLS 1.2 连接建立过程：TLS 握手的关键在于利用通信双方生成的随机字符串和服务端的公钥生成一个双方经过协商后的密钥，通信双方后续使用这个对称密钥加密数据，防止中间人监听和攻击，保障通信安全。在 TLS 1.2 中，需要 2-RTT（Round-Trip Time，往返延迟）才能建立 TLS 连接。在 TLS 1.3 中，客户端不仅发送 ClientHello、支持的协议、加密算法，还尝试猜测服务器将选择哪种密钥协商算法，并为此发送共享密钥。这样服务端选取加密算法后，因为已经有了 client key，可以立即生成 key，进而减少一次 RTT。建立连接时需要发送三个 packet，但终止连接时需要四个 packet，也称为四次挥手。因为 TCP 连接是全双工的，每个方向都必须独立终止。终止 TCP 连接的四次挥手：在第二次挥手时，如果服务端也想终止连接，可以为 FIN 设置不同于客户端 FIN 的序列号。客户端收到 FIN 后，发送 ACK，它的 acknowledgement number 为 FIN sequence number 加一。这一过程结束后，服务端与客户端的连接也终止了，这样的话整个过程进行了三次挥手。客户端想要通过 HTTP 请求访问服务端时，需要经过三次握手；通过 HTTPS 访问服务端时，需要额外增加四次握手。总结一下 HTTP 建立连接、终止连接：需要注意的是，本文所说的三次握手、七次握手、四次挥手都是基于特定版本的协议，不同版本的协议所需握手次数可能不同。HTTP/3 就是一个例子，它使用基于 UDP 的 QUIC 协议进行握手，将 TCP 和 TLS 握手过程结合起来，握手次数从七次减少到了三次。参考资料：欢迎更多指正：https://github.com/pro648/tips本文地址：https://github.com/pro648/tips /blob/master/sources/三次握手、七次握手、四次挥手.md