TCP的三次握手四次握手

HTTP是建立在TCP协议上的。

概念

TCP(Transmission Control Protocol)：传输控制协议

位码: 即TCP标志位,有6种:

• SYN(synchronous建立联机)
• ACK(acknowledgement 确认)
• PSH(push传送)
• FIN(finish结束)
• RST(reset重置)
• URG(urgent紧急)

Sequence number(顺序号码) Acknowledge number(确认号码)

其他概念:

seq: 序列号
ack: 确认序列号
ACK: 确认位码
SYN: 发起连接标志位码

简单说

3次握手:

1. 客户端发送连接请求到服务端,进入SYN-SENT 状态
2. 服务端收到客户端请求后,确认SYN成功后回复客户端,进入SYN-RCVD 状态
3. 客户端收到服务端的回复,验证ACK和ack后,给服务端回复一个确认报文,服务端确认通过后,进入ESTAB-LISHED状态,TCP连接建立成功

4次挥手:

1. 客户端向服务端发送FIN位码,表示要断开连接,并进入FIN-WAIT-1第一阶段等待状态
2. 服务端接收到客户端的断开请求后,确认FIN成功后,给客户端回复一段报文,服务端进入CLOSE-WAIT 关闭等待状态,客户端进入FIN-WAIT-2第二阶段等待状态
3. 服务端继续发送剩余的数据,等发送完后立即向客户端发送FIN和ACK位码,等待客户端确认,自身进入LAST-ACK最终确认状态
4. 客户端接收到服务端的断开请求,先确认服务端返回的报文,确认成功后给服务端发送最后的确认报文;服务端接收到确认报文后立马关闭连接,而客户端会进入2MSL(一个请求来+回的时间)的等待,之所以要等待,因为如果第四次挥手的报文丢失,服务端无法收到确认报文,就会重发第三次挥手的报文,报文一来一回的时间就是2MSL

详细版

http的3次握手":

• 第一次握手: 客户端 -> 服务端,发送连接请求,进入 SYN-SENT 状态
  • 发送SYN=1给服务端
  • 发送seq=x,序列号给服务端,seq叫做序列号,x是个随机数
  • 进入 SYN-SENT 状态
• 第二次握手: 服务端校验 + 服务端到客户端,返回请求,进入 SYN-RCVD 状态
  • 服务端收到SYN并且SYN=1,明白是客户端请求建立连接(服务端校验)
  • 返回SYN=1给客户端
  • 返回ACK=1给客户端
  • 返回seq=y,一个新的序列号,也是随机生成
  • 返回ack=x+1给客户端
  • 进入 SYN-RCVD 状态
• 第三次握手: 客户端校验 + 客户端 -> 服务端 + 服务端校验
  • 客户端收到回复发现ACK=1并且ack=x+1,也就是第一次握手时发送给服务端的seq,验证通过(客户端校验)
  • 客户端发送ACK=1给服务端
  • 客户端发送seq=x+1,ack=y+1
  • 服务端收到后发现 ACK=1并且ack=y+1,验证成功,连接建立成功

4次挥手:

假如:
建立连接时(第一次握手)的seq=x,客户端共发送了n个字节的数据;
服务端初始(第二次我搜狐)返回的seq=y,服务端共发送了m个字节的数据.

• 第一次挥手: 客户端 -> 服务端
  • 客户端向服务端发送FIN=1
  • seq=u,u=x+1+n(其中的1是建立连接时占的一个序列号)
  • 进入: SYN-WAIT2 状态
  • 此时客户端不再发送数据,但还可以接收数据
• 第二次挥手: 关闭等待状态: 服务端验证 + 服务端 -> 客户端
  • 服务端收到 FIN并且FIN=1,知道客户端想要断开连接(服务端验证)
  • 返回ACK=1给客户端
  • 返回seq=v给客户端,v=y+m
  • 返回ack=u+1给客户端
  • 进入CLOSE-WAIT状态,这时不是立马发送FIN给客户端,因为可能还有数据没有发送完
• 第三次挥手: 数据发送完成: 服务端 -> 客户端
  • 服务端将最后的数据(如 o个字节)发送完毕后向客户端发送释放报文: FIN=1
  • 服务端发送ACK=1给客户端
  • 服务端发送seq=w给客户端,w=v+o
  • 服务端发送ack=u+1给客户端,这个ack与第二次挥手的值一样
• 第四次挥手: 客户端验证 + 客户端 -> 服务端 + 服务端验证
  • 客户端收到服务端的FIN并且FIN=1,知道服务端同意关闭连接(客户端验证)
  • 客户端发送ACK=1给服务端(客户端确认报文, 客户端 -> 服务端)
  • 客户端发送ack=w+1给服务端(客户端确认报文, 客户端 -> 服务端)
  • 客户端发送seq=u+1给服务端(客户端确认报文, 客户端 -> 服务端)
  • 客户端进入2MSL的等待期(最长报文段寿命的2倍时长)后释放TCP连接
  • 服务端收到客户端的确认报文后立马释放TCP连接,所以服务端结束TCP连接的时间要比客户端早一些。

第四次挥手后为什么要进行2MSL时间的等待?
考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

HTTP2 比 HTTP1.X 的优势

• 增加二进制解析，1.x是文本解析
• 多路复用： 即连接共享，原来是一次请求一个连接建立和断开过程，现在支持一次连接可以进行多次请求，解决了同域名下并行下载数量的限制(chrome是6个，其他浏览器也不会超过10个)
• 头部压缩，减小了数据包大小

TCP三次握手和四次挥手的好处

确保数据的安全和完整。

响应头: 服务器会告诉浏览器数据的长度，浏览器数据长度和响应头数据长度相同，说明数据已经接收完毕了。

TCP和UDP对比

• TCP连接的建立要通过3次握手和4次挥手,确保数据传输的完整性和安全性
• UDP连接没有TCP复杂,通过暴力手段传输数据,而不管接收方是否能全部接受到,常见应用有: 音视频通话
• TCP面向连接,拥有可靠性,有序性,UDP都没有这些优点
• TCP有流量控制能力,TCP通常在发送包之前会测试网络的快慢情况
• TCP是重量级的,UDP是轻量级的: 因为TCP要保证可靠性和有序性，所以TCP数据报文报头的信息量大，报头大小是20个字节，UDP报头的大小是8个字节。所以TCP占用的系统的开销大。
• TCP没有数据边界,UDP有数据边界: 因此TCP容易发生粘包的现象。在UDP中数据包是单独发送的，只有当他们到达时才会再次集成，包有明确的界限来判断哪些包已经收到。
• UDP用来:在线视频媒体，电话视频聊天，qq聊天，电视广播，多人在线游戏,DOS攻击也是利用UDP,是利用牺牲传输可靠性换取时实性