TCP的三次握手和四次挥手

一、网络七层协议

OSI七层协议模型主要是：物理层（Physical）、数据链路层（Data Link）、网络层（Network）、传输层（Transport）、会话层（Session）、表示层（Presentation）、应用层（Application）

（1）物理层

主要定义物理设备标准，如网线的接口类型、各种传输介质的传输速率等。主要作用是传输比特流（就是由1、0转化为电流强弱来进行传输，到达目的地后再转化为1、0，也就是常说的数模与模数转换）。这一层的数据叫做比特（bit），主要设备：集线器

（2）数据链路层

主要将从物理层接收的数据进行MAC地址的封装与解封装。常把这一层叫做帧，主要设备：网卡，交换机

（3）网络层

选择合适的网间路由和交换结点，确保数据及时传送，将从下层接收到的数据进行P地址的封装与解封装。常把这一层数据叫做数据包，主要设备：路由器

（4）传输层

定义了一些传输数据的协议和端口，如TCP、UDP协议，主要将从下层接收的数据进行分段和传输，到达目的地址后再进行重组，以往把这一层数据叫做段。

TCP的应用：文件传输对数据完整性要求高，传输中如果丢失数据会导致整个文件损坏无法打开，所以传输层会针对文件传输类的工作，选用TCP协议

UDP的应用：语音视频通话属于实时采集的数据发送的并不是一个事先准备好的文件，所以没有文件完整性一说，而是采集多少数据就传输多少数据，这时传输层则会选择忽略完整性检查，但是速度更快延迟更小的UDP协议。

（5）表示层
主要是进行对接收数据进行解释、压缩与解压缩等，即把计算机能够识别的东西转化成人能够识别的东西（如图片、声音等）。理解：对APP数据进行编码

如：

用BMP或JPEG编码，来表示图片数据

用WAV或MP3编码，来表示声音数据

用WMV或AVI编码，来表示视频数据

（6）会话层

通过传输层建立数据传输通路。在系统之间发起会话或者接受会话请求（设备之间需要互相认识）

理解：建立两个APP之间的会话。

（7）应用层

主要是一些终端的应用，比如说浏览器、APP等可以看到的东西，也就是终端应用。

二、TCP和UDP

TCP——传输控制协议（Transmission Control Protocal）：TCP是一种面向有连接的传输层协议，能够对自己提供的连接实施控制。适用于要求可靠传输的应用，例如文件传输、发送邮件、浏览网页。面向字节流，传输慢。

UDP——用户数据协议（User Data Protocol）：UDP是一种面向无连接的传输层协议，不会对自己提供的连接实施控制。适用于实施应用，例如：IP电话、视频会议、直播等。以报文的方式传输，效率高。

二者的区别：

• TCP是基于连接的；而UDP是基于非连接的
• TCP传输数据稳定可靠，传递速度慢，适用于对网络通讯质量要求较高的场景，需要准确无误地传输给对方；UDP传输数据部稳定，容易丢包，但是传递速度快，所以适用于对实时性要求较高但是对少量丢包并没有太大要求的场景。
• TCP传输不安全，容易受到DOS、DDOS、CC等攻击；UDP相对TCP安全一些，但是UDP也无法避免遭受攻击。
• TCP是一对一连接；UDP是一对多或多对多连接（UDP支持一对一、一对多、多对多、多对一通信 而TCP只支持一对一通信。）

延伸

UDP是面向报文的，所谓「面向报文」就是指：UDP数据传输的单位是报文，且不会对数据做任何 拆分 和 拼接 操作。在发送端，应用程序给传输层的UDP什么样的数据，UDP不会对数据进行拆分，只增加一个UDP头并交给网络层。在接收端，UDP收到网络层的数据报文后，去除IP数据报头部后便交给应用层，不会做任何拼接操作。

UDP没有拥塞控制，UDP始终以恒定的速率发送数据，并不会根据网络拥塞情况对发送速率做调整。这种方式有利有弊。弊端：网络拥塞时有些报文可能会丢失，因此UDP不可靠。优点：有些使用场景允许报文丢失，如：直播、语音通话，但对实时性要求很高。

UDP首部开销小，只有8字节。而TCP头部至少由20个字节，UDP相比于TCP要高效很多。

UDP报文头：

•  源端口
• 目的端口
• 长度：整个数据报的长度
• 检验和：整个数据报的检验和

TCP是面向字节流的 所谓「面向字节流」指的是：TCP以字节为单位。虽然传输的过程中数据被划分成一个个数据报，但这只是为了方便传输，接收端最终接收到的数据与发送端的数据一模一样。

TCP提供全双工通信，所谓「全双工通信」指的是：TCP的两端既可以作为发送端，也可以作为接收端。

一条TCP连接的两端只能有两个端点，TCP只能提供点到点的通信，而UDP可以任意方式的通信。

• 什么是「TCP连接」？TCP连接是一种抽象的概念，表示一条可以通信的链路。每条TCP连接有且仅有两个端点，表示通信的双方。且双方在任意时刻都可以作为发送者和接收者。
• 什么是「套接字」？一条TCP连接的两端就是两个套接字。套接字=IP地址：端口号。因此，TCP连接=（套接字1，套接字2）=（IP1:端口号1，IP2:端口号2）

TCP头部

 TCP头部长度有20个字节的固定部分，选项部分长度不定，但最多40个字节，因此TCP头部在20-60字节之间。

三、TCP通信的过程

三次握手建立连接、四次挥手断开连接。

（1）三次握手

• 客户端发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的，并且将报文中的SYN字段置为1，表示需要建立TCP连接。（SYN=1，seq=x，x为随机生成值）；
• 服务端回复客户端发送的TCP连接请求报文，其中包含seq序列号，是由服务端随机生成的，并且SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。（SYN=1，ACK=x+1，seq=y，y为随机生成数值）这里的ack加1可以理解为是确认和谁建立连接。
• 客户端收到服务端发送的TCP建立验证请求后，会使自己的序列号加1表示，并且再次回复ACK验证请求，在服务端发过来的seq上加1进行回复（SYN=1，ACK=y+1，seq=x+1）

（2）四次挥手

刚开始双方处于ESTABLISHED状态

• 客户端发送断开TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的，并且还将报文中的FIN字段置为1，表示需要断开TCP连接。（FIN=1，seq=x，x由客户端随机生成）；此时客户端处于FIN_WAIT1状态。
• 服务端会回复客户端发送的TCP断开请求报文，其中包含seq序列号，是由服务端随机生成的，而且会产生ACK字段，ACK字段数值是在客户端发过来的seq序列号基础上+1进行回复，以便客户端在收到信息时，知晓自己的TCP断开请求已经得到验证。（FIN=1，ACK=x+1，seq=y，y由服务端随机生成）。此时服务端处于CLOSE_WAIT状态，客户端处于FIN_WAIT2状态
• 服务端在回复完客户端的TCP断开请求后，不会马上进行TCP连接的断开，服务端会先确保断开前，所有传输到客户端的数据是否已经传输完毕，一旦确认传输数据完毕，服务端就会将回复报文的FIN字段置为1，并且产生随机seq序列号。（FIN=1，ACK=x+1，seq=z，z由服务端随机生成）此时服务端处于LAST_ACK状态，客户端处于TIME_WAIT状态
• 客户端收到服务端的TCP断开请求后，客户端发送回复服务端的断开请求，包含随机生成的seq序列号字段和ACK字段，ACK字段会在服务端的TCP断开的请求的seq基础上+1，从而完成服务端请求的验证回复。（FIN=1，ACK=z+1，seq=h，h为客户端随机生成）。此时客户端处于TIME_WAIT状态，需要过了一定时间（2MSL）之后，客户端才变为CLOSE状态，以确保发送方的ACK可以到达接收方，防止已失效连接请求报文段出现在此连接中。至此TCP断开的4次挥手过程完毕。

等待计时器（TIME_WAIT）

MSL(Max Segment Lifetime):最长报文段寿命

等待计时器等待的时间为2MSL，MSL一般设置为2分钟。

在这段时间内如果客户端没有收到服务端的重发请求，那么表示ACK成功到达，挥手结束，否则客户端重发ACK。

• 

 为什么需要等待2MSL？

如果不等待，客户端直接跑路，当服务端还有很多数据包要给客户端发且还在路上的时候，若客户端的端口此时刚好被新的应用占用，那么就接收到了无用数据包，造成数据混乱。所以，最保险的做法就是等服务端发来的数据都失效后再启动新的应用。

1、确保发送方发送的第四次挥手ACK报文可以到达接收方

在第四次挥手时，只要发送方发出了第四次挥手的报文之后，发送方就进入了等待状态，这时最后一个报文其实是没有确认的，这个等待计时器主要是为了确保发送方发送的第四次挥手ACK报文可以到达接收方

1MSL是报文在网络中最长可以存活的时间，在1MSL时间里，如果第四次挥手ACK报文没有到达服务端接收方会重新发送第三次挥手的报文给客户端，客户端收到之后，就知道之前第四次挥手的ACK报文丢失了，然后再次发送ACK报文。确保正确地结束这次连接

假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一旦这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

2、确保当前连接的所有报文都已过期，防止失效的连接请求报文段出现在本连接中

因为最后一个报文都已经等待2MSL时间，所以对于其他报文，肯定也超过2MSL的时间，都是过期的报文

为什么是等待2MSL而不是1MSL？

在第四次挥手时，发送方发送ACK报文，如果服务端等1MSL没有收到发送方的ACK报文，那么说明ACK报文丢失了，此时服务端会再次重新发送第三次挥手的报文给客户端。这样从发送方发送ACK报文同时发送方进入TIME_WAIT状态等待开始，相当于两次报文传输的过程，每一次都是1MSL，两次就是2MSL。所以是等待2MSL。

为什么是四次挥手而不是三次？

因为服务端在接收到FIN，往往不会立即返回FIN，必须等到服务端所有的报文都发送完毕了，才能发FIN。因此先发一个ACK（第二次挥手）表示已经收到客户端的FIN，延迟一段时间才发FIN。这就造成了四次挥手。

如果是三次挥手会有什么问题？

等于说服务端将第二次挥手和第三次挥手合并为一次挥手（把第二次挥手的数据放到第三次挥手时一起发送），这个时候长时间的延迟可能会导致客户端误以为FIN没有到达服务端，从而让客户端不断的重发FIN。

为什么是三次握手而不是两次？

如果没有第三次握手告诉服务端，客户端已经收到了服务端传输的数据的话，服务器端的端口就会一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。长此以往，这样的端口越来越多，就会造成服务器开销的浪费。

总结：如果没有第三次握手，由于第二次握手的过程中数据可能存在丢失问题，导致客户端没有收到，但是服务端以为客户端收到了，实际上客户端没有收到，因此客户端就在一直等服务器发送数据，如果超时，就重新发起新的三次握手连接请求。但是服务端在第二次握手完成后，即服务端发送完报文之后，它以为客户端能够接收到自己发送的报文，它以为它们之间已经建立了链接，所以就一直在等客户端发送数据，导致整个过程循环，由于客户端在不停的创建连接，服务端会一直打开新的端口，长此以往，这样的端口越来越多，造成服务端资源的浪费。

三次握手可以携带数据么？

第三次握手的时候，是可以携带数据的。但是第一次、第二次握手不可以携带数据。

举个例子，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，每次都在第一次握手中的SYN报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发SYN报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

而对于第三次的话，此时客户端已经处于ESTABLISHED状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以携带数据是没问题的。

三、HTTPS

TCP是传输层协议，而HTTPS是应用层协议。HTTPS是要基于TCP连接基础上的。

HTTPS是一种安全协议，它将HTTP传输协议与SSL/TLS加密协议结合在一起，使用公钥和私钥实现数据加密和解密。HTTPS不仅保护了用户的隐私信息，还能防止网络攻击者篡改或窃取数据。

（1）加密传输：HTTPS通过SSL加密技术将通信数据加密，非法用户无法解密获取有用信息，保证了数据传输过程中的安全性

（2）证书验证：HTTPS要求网站拥有合法的SSL证书。浏览器会对证书进行验证，若网站有问题，则会出现”不受信任的证书“警告。这样可以保证用户通过HTTPS访问的网站都是可信的。

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用加密确保私密性，以实现客户端和服务端之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议

TLS：（Transport Layer Security，传输层安全协议），用于两个应用程序之间提供保密性和数据完整性。

其实HTTPS在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

 1、证书验证阶段

（1）浏览器发起HTTPS请求

（2）服务端返回HTTPS证书

（3）客户端验证证书是否合法，如果不合法则提示告警

2、数据传递阶段

（1）当证书验证合法后，在本地生成随机数

（2）通过公钥加密随机数、并把加密后的随机数传输到服务端

（3）服务端通过私钥对随机数进行解密

（4）服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

为什么数据传输是用对称加密？

首先，非对称加密的加解密效率是非常低的，而http的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受。

另外，在HTTPS的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以HTTPS中内容传输加密采取的是对称加密，而不是非对称加密。

为什么需要CA 认证机构颁发证书？

HTTP协议被认为不安全是因为传输过程中容易被监听者勾线监听、伪造服务器，而HTTPS协议主要解决的便是网络传输的安全性问题。首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的**中间人攻击**问题。

证书包含什么信息？

• 颁发机构信息
• 公钥
• 公司信息
• 域名
• 有效期
• 指纹
• ...

浏览器如何验证证书的合法性？

浏览器发起HTTPS请求时，服务器会返回网站的SSL证书，浏览器需要对证书做以下验证：

（1）验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；

（2）判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证。

参考：HTTPS为什么安全_九城风雪的博客-CSDN博客