【计算机网络】Web及网络基础——网页是怎么打开的（个人笔记）

ender670

已于 2024-06-18 18:42:19 修改

阅读量1k

点赞数 37

分类专栏：计算机网络 HTTP TCP/IP 文章标签：计算机网络

于 2024-06-18 09:00:00 首次发布

本文链接：https://blog.csdn.net/weixin_62679382/article/details/139752723

版权

计算机网络同时被 3 个专栏收录

6 篇文章 0 订阅

订阅专栏

HTTP

5 篇文章 0 订阅

订阅专栏

TCP/IP

4 篇文章 0 订阅

订阅专栏

学习日期：2024.6.17

内容摘要：简述HTTP通信过程和原理

内容总结自人民邮电出版社《图解HTTP》

使用HTTP协议访问Web

我们知道，只需要在网页浏览器的地址栏中输入网址，按下回车，网页就出现了，但这一过程是怎么实现的呢？

显然Web页面不是凭空显示的，通过我们指定的URL（网址），Web浏览器从服务器端获取文字图片等资源信息，然后显示出页面，Web浏览器可称为客户端（client）。

Web使用一种叫HTTP（HyperText Transfer Protocol，超文本传输协议）的协议作为规范，完成客户端到服务器端的通信。

（协议：计算机和网络设备互相通信的规则）

网络基础TCP/IP

通常使用的网络是在TCP/IP协议族的基础上运作的，HTTP属于它的一个子集

TCP/IP协议是分层的，按层次分为应用层、传输层、网络层和数据链路层。

层次化的好处在于，如果哪个层次需要更新，只需要替换对应的部分即可。

应用层：好比服务生，直接向用户提供应用服务时的通信活动。比如FTP（File Transfer Protocol，文件传输协议）和DNS（Domain Name System，域名系统）就属于此类，HTTP也处于这层。

传输层：提供处于网络连接中两台计算机之间的数据传输。传输层有两个性质不同的协议，分别是TCP（Transmission Control Protocol，传输控制协议）和UDP（User Data Protocol，用户数据报协议）

网络层：网络层好比导航系统，规定了该通过怎样的路径（即传输路线）到达对方的计算机，并把数据包传给对方。IP（Internet Protocol，网际协议）就位于这层。注意区分IP和IP地址，IP是一种协议的名称，IP地址是节点被分配到的地址。

链路层：处理连接网络的硬件系统。包括控制硬件和操作系统的驱动、NIC（Network Interface Card，网络适配器，俗称网卡）、光纤之类物理可见的部分。

利用TCP/IP协议通信时，会按分层顺序通信，发送端自应用层向下走，即应用层->传输层->网络层->链路层，接收端则反之。

一次HTTP请求的过程——寄快递

以HTTP为例，类比生活中寄快递。

首先客户端在应用层（HTTP协议）发出请求，就是联系快递员，说“我要寄快递啦”。

然后为了传输方便，传输层（TCP协议）把从应用层收到的数据（HTTP请求报文）分割，并且在各个报文上打上标记序号及端口，再传给网络层。好比快递员把你要寄出的奇形怪状的东西用纸箱子包好，方便运输。

在网络层（IP协议），增加作为通信目的地的MAC地址后转发给链路层。前面说了，网络层好比导航，按地址找到目的地之后再交给链路层（把你的快递送过去的运输大卡车）

接收端的服务器在链路层收到数据，再按序向上发送，一直到应用层，直到接收端传输到应用层时，才算真正接收到客户端发过来的HTTP请求。

发送端在层与层之间传输数据时，每经过一层都要打上一个该层的首部信息，同样，接收端每经过一层就会消去一个首部信息，这种把数据信息包装起来的做法叫封装。

IP、TCP和DNS

负责传输的IP协议

Internet Protocol这个名字可谓威武霸气，事实也是如此，几乎所有使用网络的系统都会使用它

IP协议的主要作用是把各种数据包传给对方，要保证这一点，就需要IP地址和MAC地址（Media Access Control Address)

IP地址是节点被分配的地址，MAC地址是网卡所属的固定地址，IP地址可变，MAC地址几乎不会更改。

显然，现实中通信的双方很少处于同一个局域网下，这就需要通信的双方中转，中转时会利用下一台中转设备的MAC地址来搜索下一个中转目标，这时就需要ARP协议（Address Resolution Protocol，地址解析协议），它可以根据通信方的IP地址反查出对方的MAC地址。

确保可靠性的TCP协议（重点）

TCP协议采用著名的“三次握手，四次挥手”来保证可靠性。

首先要知道TCP的几个标志，SYN（synchronize，v.同步，时间上一致）ACK（acknowledgement，n.确认）FIN（finish，结束）

三次握手

我们想象客户端和服务器端两个小人在互相发邮件

客户端：标有SYN的数据包发给你了，收到没有？请求建立连接！（第一次握手）

服务器端：收到收到，可以建立连接！（发送含有SYN和ACK的数据包）（第二次握手）

客户端：明白！同步开始！（发送含有ACK的数据包）（第三次握手）

为什么不是两次握手：第二次握手后，服务器端知道对方的发送能力没有问题，但不知道自己的发送能力和对方的接收能力有没有问题，如果只握手两次，对方却没有接收到服务器端的回复，就会导致服务器待机，浪费资源

为什么不是114514次：三次握手比两次更可靠，但也不是完全可靠，而追加更多次握手也不能使连接更可靠了（双方的发送和接收能力都已经得到确认了），因此选择了三次握手。

四次挥手

还是那两个小人

客户端：标有FIN的数据包发给你了，收到没有？请求连接断开！（第一次挥手）

服务器端：我收到了，我先准备一下（发送含有ACK的数据包）（第二次挥手）

服务器端：我准备好了，你可以断开了（发送含有FIN的数据包）（第三次挥手）

客户端：明白！连接断开！（发送含有ACK的数据包）（第四次挥手）

为什么挥手要多一次：

因为当服务器端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务器端收到FIN报文时，很可能并不会立即关闭SOCKET（活还没干完），所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送FIN和ACK，故需要四次挥手。