你真的弄懂 HTTP 了吗？（四）

这是我参与8月更文挑战的第10天，活动详情查看：8月更文挑战git

1、说说TCP为何须要三次握手和四次挥手？

1.1 三次握手

三次握手（Three-way Handshake）其实就是指创建一个TCP链接时，须要客户端和服务器总共发送3个包github

主要做用就是为了确认双方的接收能力和发送能力是否正常、指定本身的初始化序列号为后面的可靠性传送作准备web

过程以下：服务器

第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)，此时客户端处于 SYN_SENT 状态
第二次握手：服务器收到客户端的 SYN 报文以后，会以本身的 SYN 报文做为应答，为了确认客户端的 SYN，将客户端的 ISN+1做为ACK的值，此时服务器处于 SYN_RCVD 的状态
第三次握手：客户端收到 SYN 报文以后，会发送一个 ACK 报文，值为服务器的ISN+1。此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文以后，也处于 ESTABLISHED 状态，此时，双方已创建起了链接

上述每一次握手的做用以下：websocket

第一次握手：客户端发送网络包，服务端收到了
这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了
这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常
第三次握手：客户端发包，服务端收到了。
这样服务端就能得出结论：客户端的接收、发送能力正常，服务器本身的发送、接收能力也正常

经过三次握手，就能肯定双方的接收和发送能力是正常的。以后就能够正常通讯了markdown

为何不是两次握手?

若是是两次握手，发送端能够肯定本身发送的信息能对方能收到，也能肯定对方发的包本身能收到，但接收端只能肯定对方发的包本身能收到没法肯定本身发的包对方能收到网络

而且两次握手的话, 客户端有可能由于网络阻塞等缘由会发送多个请求报文，延时到达的请求又会与服务器创建链接，浪费掉许多服务器的资源socket

1.2 四次挥手

tcp终止一个链接，须要通过四次挥手tcp

过程以下：oop

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态，中止发送数据，等待服务端的确认
第二次挥手：服务端收到 FIN 以后，会发送 ACK 报文，且把客户端的序列号值 +1 做为 ACK 报文的序列号值，代表已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态
第三次挥手：若是服务端也想断开链接了，和客户端的第一次挥手同样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态
第四次挥手：客户端收到 FIN 以后，同样发送一个 ACK 报文做为应答，且把服务端的序列号值 +1 做为本身 ACK 报文的序列号值，此时客户端处于 TIME_WAIT状态。须要过一阵子以确保服务端收到本身的 ACK 报文以后才会进入 CLOSED 状态，服务端收到 ACK 报文以后，就处于关闭链接了，处于 CLOSED 状态

四次挥手缘由

服务端在收到客户端断开链接Fin报文后，并不会当即关闭链接，而是先发送一个ACK包先告诉客户端收到关闭链接的请求，只有当服务器的全部报文发送完毕以后，才发送FIN报文断开链接，所以须要四次挥手

1.3 总结

一个完整的三次握手四次挥手以下图所示：

2、说说对WebSocket的理解？应用场景？

2.1 是什么

WebSocket，是一种网络传输协议，位于OSI模型的应用层。可在单个TCP链接上进行全双工通讯，能更好的节省服务器资源和带宽并达到实时通迅

客户端和服务器只须要完成一次握手，二者之间就能够建立持久性的链接，并进行双向数据传输

从上图可见，websocket服务器与客户端经过握手链接，链接成功后，二者都能主动的向对方发送或接受数据

而在websocket出现以前，开发实时web应用的方式为轮询

不停地向服务器发送 HTTP 请求，问有没有数据，有数据的话服务器就用响应报文回应。若是轮询的频率比较高，那么就能够近似地实现“实时通讯”的效果

轮询的缺点也很明显，反复发送无效查询请求耗费了大量的带宽和 CPU 资源

2.2 特色

全双工

通讯容许数据在两个方向上同时传输，它在能力上至关于两个单工通讯方式的结合

例如指 A→B 的同时 B→A ，是瞬时同步的

二进制帧

采用了二进制帧结构，语法、语义与 HTTP 彻底不兼容，相比http/2，WebSocket 更侧重于“实时通讯”，而HTTP/2 更侧重于提升传输效率，因此二者的帧结构也有很大的区别

不像 HTTP/2 那样定义流，也就不存在多路复用、优先级等特性

自身就是全双工，也不须要服务器推送

协议名

引入ws和wss分别表明明文和密文的websocket协议，且默认端口使用80或443，几乎与http一致

ws://www.chrono.com
ws://www.chrono.com:8080/srv
wss://www.chrono.com:445/im?user_id=xxx
复制代码

握手

WebSocket 也要有一个握手过程，而后才能正式收发数据

客户端发送数据格式以下：

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
复制代码

Connection：必须设置Upgrade，表示客户端但愿链接升级
Upgrade：必须设置Websocket，表示但愿升级到Websocket协议
Sec-WebSocket-Key：客户端发送的一个 base64 编码的密文，用于简单的认证秘钥。要求服务端必须返回一个对应加密的“Sec-WebSocket-Accept应答，不然客户端会抛出错误，并关闭链接
Sec-WebSocket-Version ：表示支持的Websocket版本

服务端返回的数据格式：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=Sec-WebSocket-Protocol: chat
复制代码

HTTP/1.1 101 Switching Protocols：表示服务端接受 WebSocket 协议的客户端链接
Sec-WebSocket-Accep：验证客户端请求报文，一样也是为了防止误链接。具体作法是把请求头里“Sec-WebSocket-Key”的值，加上一个专用的 UUID，再计算摘要

优势

较少的控制开销：数据包头部协议较小，不一样于http每次请求须要携带完整的头部
更强的实时性：相对于HTTP请求须要等待客户端发起请求服务端才能响应，延迟明显更少
保持创链接状态：建立通讯后，可省略状态信息，不一样于HTTP每次请求须要携带身份验证
更好的二进制支持：定义了二进制帧，更好处理二进制内容
支持扩展：用户能够扩展websocket协议、实现部分自定义的子协议
更好的压缩效果：Websocket在适当的扩展支持下，能够沿用以前内容的上下文，在传递相似的数据时，能够显著地提升压缩率

2.3 应用场景

基于websocket的事实通讯的特色，其存在的应用场景大概有：

弹幕
媒体聊天
协同编辑
基于位置的应用
体育实况更新
股票基金报价实时更新