本文共 2542 字，大约阅读时间需要 8 分钟。

一、HTTP

Hyper Text Transfer Protocol是一种无状态的、以请求|应答方式运行的协议。它支持可扩展的语义和自描述消息格式，与HTML可以灵活互动

• 无状态：浏览器无法识别谁连接它→cookie
• 请求应答方式：request、response
• 可扩展的语义：头部可以添加自定义标签
• 自描述消息格式：可以自己定义消息的格式，如application/json、text/html、text/plain

1. HTTP消息格式

• 可扩展的语义不要使用下划线，因为某些浏览器不会解析，建议使用’-’

2. HTTP请求的过程

① 浏览器输入网址，按下inter

② 域名解析。首先从本地缓存李查看有没有这个域名的IP地址(浏览器缓存、操作系统自身的DNS缓存、本机域名解析文件)，如果没有就向DNS服务器发送请求获取

• chrome://net-internals/#dns
• ipconfig /displaydns
• C:\Windows\System32\drivers\etc

③ TCP三次握手建立连接后→浏览器就发送HTTP请求→应用服务器就响应，发送HTML代码→浏览器解析HTML代码，然后发送请求获取JS、图片等等资源→浏览器呈现完整的页面

④ 页面关闭，就通过TCP四次挥手结束连接

3. 推荐阅读

二、TCP

Transmission Control Protocol是面向连接的、可靠的、基于字节流的传输层通信协议

• 面向连接的：数据传输之前需要先建立连接→三次握手

• 全双工：双方都有单独的管道进行通信

  

• 基于字节流：不是把数据全部一次性传输，而是打包成一段一段的，发过去后再按照顺序组合起来，就得到完整的数据

• 流量缓冲：双方都建立了一个缓冲区，以提高接收效率

• 可靠的传输服务：会保证数据到达对方，没有收到回应就会认为数据丢失了，会进行重发

• 拥塞控制：网络条件不好的话，还会动态调整每次发送的数据的大小和速度

1. TCP的报文格式

• sequence number：本段数据的第一个字节的序号，每一个字节一个序号【例如当前序号是300，数据长度是100，则下一个报文段序号是400】
• acknowledge number：指明下一个期待收到的字节序号，表名之前的数据已经成功收到，ack=1才有效
• 窗口大小：发送到告诉自己接收端的缓存大小，以来控制自己发送数据的速率啥的

2. 三次握手

① 假设服务端启动了80端口监听，进入监听状态。客户端创建发送syn包(seq=x)→进入SYN_SENT状态→等待服务端响应【创建一个数据结构，保存源端口、目的端口、地址、序号等，然后设置SYN=1,seq=x】

② 服务端收到syn包，要确认收到→设置ACK=1(ack=x+1)→自己也发送一个syn包(seq=y)→发送这个包SYN+ACK包过去，进入SYN_RECEIVED状态

③ 客户端收到SYN+ACK包后，就发送ACK(ack=y+1)，自己进入ESTABLISH状态。服务端收到后也进入ESTABLISH状态，至此，三次握手圆满结束。

注：TCP连接的第一个报文序列号（ISN）是0，那么后续每个报文的序列号是固定的。但是为了防止黑客使用TCP Spoof方法攻击，这个ISN要求是随机的，避免被黑客猜到。在Windows的不同版本，或者Linux的不同版本，这个随机的方法都不太一样。RFC1948里建议的随机算法是ISN=M+F（localhost, localport,remotehost, remoteport）其中M是一个计时器，每4毫秒加1。F是一个Hash算法，比如MD5或者SHA256。TCP协议要使用的序列号是后面报文实际携带的序列号和ISN的相对值

3. 四次挥手

① TCP客户端发送一个FIN(seq=i)，客户端进入FIN_WAIT_1状态

② 服务端收到后，发送一个ACK(ack=i+1)，服务端进入CLOSE_WAIT(因为是全双工，现在才服务端到客户端单方面关闭，所以还不是完全关闭)客户端收到ACK后，就进入FIN_WAIT_2状态

③ 所有数据都传完了，服务端发送一个FIN(seq=j)，比如close方法，进入LAST_ACK【等待最后的ack】

④ 客户端接收到FIN后，发送ACK(ack=j+1)，服务端就自己关了，客户端进入TIME_WAIT状态，会等待2MSL时间（TCP报文在Internet最长生存时间，主要还是确认网络中所有数据都接收了-比如最后一个ACK丢了，服务端会重发，客户端才知道丢了）

4. 理解TCP字节流

TCP是传输层，并不关心上一层传的数据是啥，它只管根据对方窗口和网络情况动态决定一个个 报文段的长度(另外TCP缓冲区还会去重)

5. TCP可靠性传输

5.1 停止等待协议：

客户端发送M1到服务端→服务端收到后，返回ACK→客户端再发送M2→服务端收到，返回ACK

缺点：感觉像单线程一样，效率很低

5.2 重传机制

对于数据丢包后，该怎么办呢？

​ ① ACK报文丢失：客户端发送M1，等待一段时间后，发现没收到ACK，就知道丢了，于是再发送M1，直到收到ACK

​ ② 请求报文丢失：客户段发送M1过去，M1丢了，于是隔段时间再发，直到收到ACK

5.3 滑动窗口和累计确认ack

上面的效率不高，每次接收一个报文，服务端要回复ACK，要好几十个字节，很浪费，于是设计了一个高效的类似于多线程的发送方案(滑动窗口应该是在缓冲区那里设置的一种算法)

• 思路就是客户端一次性发送多个报文，服务端接收后(会等待一下，多接受几个数据后)，回复收到的最大的序号
• 滑动窗口的大小还会收到网络情况而动态调整

三、说明

本文只是理解并参考了一部分博客，要深究的话其实还有很多知识。由于博主知识有限，有误之处还请指出!

转载地址：https://blog.csdn.net/qq_39811414/article/details/111025810 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！