TCP/IP
![](https://img.haomeiwen.com/i5908988/9339b3ee5b9e2916.png)
一、三次握手过程及状态变化
- 客户端发送SYN = 1 ACK = 0 seq = x,状态变为SYN_SENT
- 服务端初始状态LISTEN,收到客户端的链接请求之后,发送确认 SYN = 1, ACK = 1, ack = x +1, seq = y,状态变为SYN_RECEIVE
- 客户端收到服务端确认,发送ACK = 1 ack = y + 1, 客户端状态变为ESTABLISED
- 服务端收到客户端确认状态变为ESTABLISED, 连接建立
二、 为什么需要三次握手
客户端发送的第一次连接请求滞留在核心网络当中,TCP超时未收到服务端ACK,会重新发送连接请求,当客户端和服务器数据传输完毕,连接断开之后第一次发起的连接请求才到达服务端,这个时候连接已经断开,如果握手为两次,那么服务端会无条件的接受连接的请求,在回给客户端一个ACK,客户端收到之后认为连接已经断开,不会再给服务端发送确认的请求, 这个时候服务端会维护一个半连接,大量的这种连接会占用很多资源。
如果是三次握手的话, 服务端没有收到客户端的连接确认,就不会到达ESTABLISED状态,这样就不会维护这个链接。 所以三次握手是最小次数的TCP建立连接的过程。
三、四次挥手过程及状态变化
- 客户端发送FIN 报文,状态变为FIN_WAIT_1
- 服务端接收到客户端的关闭链接请求, 发送ACK确认报文, 确认关闭链接的请求, 状态变为CLOSE_WAIT
- 客户端收到服务端的关闭连接的确认,状态变为FIN_WAIT_2
- 如果服务端没有消息需要发送,服务端发送FIN报文
- 客户端收到服务端的FIN报文,会进入TIME_WAIT状态,并且给服务端发送ACK回应
- 服务端收到客户端的断开回应, 状态变为CLOSE
- 客户端会在2MSL结束后进入CLOSE状态
四、主动关闭连接一方为什么需要TIME_WAIT
- 为了防止延迟数据
连接TIME_WAIT期间其他应用程序是不能该链接的,之后在该连接彻底释放之后才能复用,如果TIME_WAIT时间比较短会导致滞留在核心网络的数据会被复用之后的连接收到(还是有几率收到的,除此之外还有序号保证) - 为了保证连接彻底关闭
服务端如果没有收到客户端的ACK ,客户端链接断开, 重新复用的连接请求发送到服务端,服务端会认为不合法,返回RST导致连接必须被释放
五、TCP报文格式
![](https://img.haomeiwen.com/i5908988/4fe19b4add027b33.png)
- 默认20个字节的固定首部
六、UDP 报文格式
![](https://img.haomeiwen.com/i5908988/e12dda3cd08ea8e7.png)
- 分别为源ip、目标ip、长度、校验和,分别占2个字节,共8个字节
七、TCP、UPD区别
- TCP面向链接、可靠, UDP 不需要建立连接、不可靠
- 头部不相同
八、HTTP协议
HTTP 各版本区别
HTTP 1.0、HTTP 1.1 HTTP 2.0
HTTP 1.0
- HTTP 1.0每个TCP连接只能发送一个网络请求,结束之后就要断开,TCP创建链接需要三次握手,非常耗时
HTTP1.1
- header默认加入 Connection:keep-alive 默认开启
- keep-alive:保持客户端和服务器的链接, 受到timeout和max字段的影响,前者指的是一定时间内没有新的请求,后者指的是发起请求的次数超过了max 链接才会断开。
- 如何判断本次请求结束,需要通过Content-length
- Http1.1采用流式传输,
- Http 1.1 管道化,可以同时发送请求, 服务器按照顺序返回给客户端
- 断点传输
HTTP 2.0
1.头部压缩
- 二进制分帧:基于二进制流,最小的数据单位为帧,每一帧都有一个序号标志着它属于哪路流
3.多路复用:同一条tcp连接上可以进行多次请求和响应,没有严格的顺序,在对端做数据组装
HTTPS握手过程
- 首先需要TCP握手建立链接
- 客户端发送所支持的对称加密版本和一个随机数给服务端
- 服务端收到之后选择一个对称加密的算法,并给出数字证书和一个随机数发送给客户端
- 客户端需要验证证书合法性,验证通过之后生成一个随机数并使用证书里的公匙加密,发送给服务端
- 服务端收到客户端发来的随机数,用自己的私匙解密
- 客户端使用约定好的对称加密算法和三个随机数生成对话密匙,用来加密接下来的整个通信过程
- HTTPS数字签名: 为了验证发送者身份, 对证书内容做摘要然后用私匙加密,跟随证书一起发送给客户端,客户端收到之后用公钥解密,然后获得摘要,然后对比验证证书合法性
- 客户端取服务端的公匙需要通过证书的公匙取解密得到服务端的公匙和签名
WebSocket
1.TCP建立连接之后需要握手如下:
The handshake from the client looks as follows:
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
The handshake from the server looks as follows:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
基于HTTP get 做协议升级
- WebSocket解决了什么问题
早期使用Http协议轮训查询服务状态的方式会传输大量的头信息,真实数据部分可能很小,会造成很多的资源浪费,又不能实现服务端向客户端推送消息的功能,WebSocket解决了这两个问题,握手阶段发送完header就不需要在发送了, 但是需要Ping-Pong 来维持链接的稳定,因为在核心网络的各个节点中可能会因为当前链接长时间没有数据交换而被关闭。
网友评论