计算机网络
约 3843 字大约 13 分钟
2025-01-18
1.计算机网络基础
1.1 OSI七层模型
- 应用层:为计算机用户提供服务
- 表示层:数据处理,如编解码、加密解密
- 会话层:建立、维护、重连应用程序之间的会话
- 传输层:提供数据传输服务
- 网络层:路由寻址
- 数据链路层:桢编码和误差纠正控制
- 物理层:传送比特流传输
1.2 TCP四层模型
TCP/IP 四层模型是OSI七层模型
应用层:
- 应用层
- 表示层
- 会话层
传输层
网络层
网络接口层
- 数据链路层
- 物理层
1.3 应用层协议
- HTTP:超文本传输协议,传输超文本和多媒体内容的协议
- SMTP:发送电子邮件的协议
- FTP:文件传输协议
- DNS:基于 UDP 协议,用于解决域名和 IP 地址的映射问题。
1.4 网络层协议
- IP:TCP/IP 协议中最重要的协议之一,属于网络层的协议,主要作用是定义数据包的格式、对数据包进行路由和寻址;
- ARP地址解析协议:地址解析协议,ARP 协议解决了 IP 地址转 MAC 地址的一些问题。
- ICMP:一种用于传输网络状态和错误消息的协议,常用于网络诊断和故障排除。例如,Ping 工具就使用了 ICMP 协议来测试网络连通性。
2.HTTP
2.1 用户从输入URL到页面展示发生的内容
- 在浏览器中输入指定网页的 URL。
- 浏览器通过 DNS 协议,获取域名对应的 IP 地址。
- 浏览器根据 IP 地址和端口号,向目标服务器发起一个 TCP 连接请求。
- 浏览器在 TCP 连接上,向服务器发送一个 HTTP 请求报文,请求获取网页的内容。
- 服务器收到 HTTP 请求报文后,处理请求,并返回 HTTP 响应报文给浏览器。
- 浏览器收到 HTTP 响应报文后,解析响应体中的 HTML 代码,渲染网页的结构和样式,同时根据 HTML 中的其他资源的 URL(如图片、CSS、JS 等),再次发起 HTTP 请求,获取这些资源的内容,直到网页完全加载显示。
- 浏览器在不需要和服务器通信时,可以主动关闭 TCP 连接,或者等待服务器的关闭请求
2.2 HTTP和HTTPS的区别
- 端口号:HTTP 默认是 80,HTTPS 默认是 443;
- 安全性:HTTP的数据是明文传输,安全性差;HTTPS的数据传输过程是加密的,安全性好
- 响应速度:HTTP响应速度快,基于TCP,需要交换3个包;HTTP是基于SSL,还要9个包
- 资源消耗:HTTP协议基于TCP协议构建,HTTPS协议基于SSL,消耗更多资源
2.2.1 对称性加密/非对称性加密
- 对称性加密:加密和解密使用的是同一个密钥,即加密和解密的过程是对称的
- 非对称性加密:使用两个密钥:公钥和密钥,公钥用于加密信息,私钥用于解密信息。公钥可以公开,而私钥必须保密
2.2.2 HTTPS加密过程
HTTP传输数据分为证书验证和数据传输两个阶段,其中证书验证阶段使用非对称加密,数据传输阶段使用对称加密
证书验证阶段:
- 浏览器发起 HTTPS 请求
- 服务端返回 HTTPS 证书(包含公钥)
- 客户端验证证书是否合法,如果不合法则提示告警
- 密钥交换,并保存会话密钥
数据传输阶段:
- 当证书验证合法后,在本地生成随机数
- 通过公钥加密随机数,并把加密后的随机数传输到服务端
- 服务端通过私钥对随机数进行解密
- 服务端通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密后传输
1、为什么数据传输使用对称加密?
- 非对称加密的加解密效率是非常低的
- 在 HTTPS 的场景中只有服务端保存了私钥,一对公私钥只能实现单向的加解密
2.3 GET和POST的区别
GET 和 POST 是 HTTP 协议中两种常用的请求方法,它们在不同的场景和目的下有不同的特点和用法。一般来说,可以从以下几个方面来区分二者(重点搞清两者在语义上的区别即可):
作用:GET 通常用于查询资源;POST 通常用于创建或修改资源
幂等:GET 请求是幂等的;POST 请求是不幂等的
请求参数格式:
GET 请求的参数通常放在 URL 中,形成查询字符串,GET 请求的 URL 长度受到浏览器和服务器的限制
POST 请求的参数通常放在请求体(body)中,可以有多种编码格式,如 application/x-www-form-urlencoded、multipart/form-data、application/json 等。而 POST 请求的 body 大小则没有明确的限制。不过,实际上 GET 请求也可以用 body 传输数据,只是并不推荐这样做,因为这样可能会导致一些兼容性或者语义上的问题。
缓存
- 由于 GET 请求是幂等的,它可以被浏览器或其他中间节点(如代理、网关)缓存起来,以提高性能和效率
- POST 请求则不适合被缓存,因为它可能有副作用,每次执行可能需要实时的响应。
2.4 常见的HTTP状态码
大体的1xx、2xx、3xx、4xx、5xx状态码
- 1xx:信息性状态码,接收的请求正在处理。
- 2xx:成功状态码,请求正常处理完毕。
- 3xx:重定向状态码,需要后续操作才能完成这一请求。
- 4xx:客户端错误状态码,请求包含语法错误或无法完成。
- 5xx:服务器错误状态码,服务器在处理请求的过程中发生了错误
各大类下常见的状态码
2.4.1 4xx状态码
状态码 | 英文描述 | 中文描述 |
---|---|---|
400 | Bad Request | 客户端请求的语法错误,服务器无法理解 |
401 | Unauthorized | 请求要求用户的身份认证 |
403 | Forbidden | 服务器理解请求客户端的请求,但是拒绝执行此请求 |
404 | Not Found | 服务器无法根据客户端的请求找到资源(网页) |
405 | Method Not Allowed | 客户端请求中的方法被禁止 |
2.4.2 5xx状态码
状态码 | 英文描述 | 中文描述 |
---|---|---|
500 | Internal Server Error | 服务器内部错误,无法完成请求 |
501 | Not Implemented | 服务器不支持请求的功能,无法完成请求 |
502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应 |
503 | Service Unavailable | 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
2.5 HTTP1.0、1.1、2.0、3.0区别
HTTP1.1
- 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销.
- 支持管道(pipeline)网络传输, 只要第一个请求发出去了, 不必等其回来, 就可以发第二个请求出去, 可以减少整体的响应时间.
HTTP2.0
- 头部压缩
- 二进制格式,HTTP1.0使用的是纯文本
- 多路复用,实现了真正的并发请求
- 服务端推送
HTTP3.0:放弃 TCP ,使用 UDP
2.6 为什么HTTP3.0使用了UDP
为了解决 HTTP 2.0 中由于使用 TCP 导致的队头堵塞问题和连接时间过长的问题.
本质上是将 TCP 的重要功能转移到了用户态来解决, 不在内核中解决.
3.DNS
3.1 DNS的作用
DNS(Domain Name System)域名管理系统,当用户使用浏览器访问网址之后,使用的第一个重要协议。
DNS 解决了域名和 IP 地址的映射问题。
在一台电脑上,可能存在浏览器 DNS 缓存,操作系统 DNS 缓存,路由器 DNS 缓存。如果以上缓存都查询不到,那么 DNS 就闪亮登场了。
目前 DNS 的设计采用的是分布式、层次数据库结构,DNS 是应用层协议,它可以在 UDP 或 TCP 协议之上运行,端口为 53
4.TCP与UDP
4.1 TCP与UDP的区别
是否面向连接:
- UDP 在传送数据之前不需要先建立连接。
- TCP 提供面向连接的服务,在传送数据之前必须先建立连接,数据传送结束后要释放连接。
是否是可靠传输:远的主机在收到 UDP 报文后,不需要给出任何确认,并且不保证数据不丢失,不保证是否顺序到达。TCP 提供可靠的传输服务,TCP 在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制。通过 TCP 连接传输的数据,无差错、不丢失、不重复、并且按序到达。
是否有状态:这个和上面的“是否可靠传输”相对应。TCP 传输是有状态的,这个有状态说的是 TCP 会去记录自己发送消息的状态比如消息是否发送了、是否被接收了等等。为此 ,TCP 需要维持复杂的连接状态表。而 UDP 是无状态服务,简单来说就是不管发出去之后的事情了(这很渣男!)。
传输效率:由于使用 TCP 进行传输的时候多了连接、确认、重传等机制,所以 TCP 的传输效率要比 UDP 低很多。
传输形式:TCP 是面向字节流的,UDP 是面向报文的。
首部开销:TCP 首部开销(20 ~ 60 字节)比 UDP 首部开销(8 字节)要大。
是否提供广播或多播服务:TCP 只支持点对点通信,UDP 支持一对一、一对多、多对一、多对多;
TCP | UDP | |
---|---|---|
是否面向连接 | 是 | 否 |
是否可靠 | 是 | 否 |
是否有状态 | 是 | 否 |
传输效率 | 较慢 | 较快 |
传输形式 | 字节流 | 数据报文段 |
首部开销 | 20 ~ 60 bytes | 8 bytes |
是否提供广播或多播服务 | 否 | 是 |
4.2 TCP三次握手
建立一个 TCP 连接需要“三次握手”,缺一不可:
- 一次握手:客户端发送带有 SYN(SEQ=x) 标志的数据包 -> 服务端,然后客户端进入 SYN_SEND 状态,等待服务器的确认;(x为客户端的序列号)
- 二次握手:服务端发送带有 SYN+ACK(SEQ=y,ACK=x+1) 标志的数据包 –> 客户端,然后服务端进入 SYN_RECV 状态(ACK即服务器确认收到客户端的序列号,后加一返回)
- 三次握手:客户端发送带有 ==ACK(ACK=y+1) 标志的数据包 –> 服务端,然后客户端和服务器端都进入ESTABLISHED 状态,完成 TCP 三次握手。
三次握手的目的是建立可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
- 第一次握手:Client 什么都不能确认;Server 确认了对方发送正常,自己接收正常
- 第二次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:对方发送正常,自己接收正常(还差确认自己发送、对方接送正常)
- 第三次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己发送、接收正常,对方发送、接收正常
Client角度 | 第一次握手 | 第二次握手 | 第三次握手 |
---|---|---|---|
Client 自己发送正常 | √ | ||
Server 对方接收正常 | √ | ||
Server对方发送正常 | √ | ||
Client自己接收正常 | √ |
Server角度 | 第一次握手 | 第二次握手 | 第三次握手 |
---|---|---|---|
Client 对方发送正常 | √ | ||
Server 自己接收正常 | √ | ||
Server自己发送正常 | √ | ||
Client对方接收正常 | √ |
4.3 TCP四次挥手
断开一个 TCP 连接则需要“四次挥手”,缺一不可:
- 第一次挥手:客户端发送一个 FIN(SEQ=x) 标志的数据包->服务端,用来关闭客户端到服务器的数据传送。然后客户端进入 FIN-WAIT-1 状态。
- 第二次挥手:服务器收到这个 FIN(SEQ=X) 标志的数据包,它发送一个 ACK (ACK=x+1)标志的数据包->客户端 。然后服务端进入 CLOSE-WAIT 状态,客户端进入 FIN-WAIT-2 状态。
- 第三次挥手:服务端发送一个 FIN (SEQ=y)标志的数据包->客户端,请求关闭连接,然后服务端进入 LAST-ACK 状态。
- 第四次挥手:客户端发送 ACK (ACK=y+1)标志的数据包->服务端,然后客户端进入TIME-WAIT状态,服务端在收到 ACK (ACK=y+1)标志的数据包后进入 CLOSE 状态。此时如果客户端等待 2MSL 后依然没有收到回复,就证明服务端已正常关闭,随后客户端也可以关闭连接了。
只要四次挥手没有结束,客户端和服务端就可以继续传输数据!
TCP 是全双工通信,可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入==半关闭状态==。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了 TCP 连接。
举个例子:A 和 B 打电话,通话即将结束后。
- 第一次挥手:A 说“我没啥要说的了”
- 第二次挥手:B 回答“我知道了”,但是 B 可能还会有要说的话,A 不能要求 B 跟着自己的节奏结束通话
- 第三次挥手:于是 B 可能又巴拉巴拉说了一通,最后 B 说“我说完了”
- 第四次挥手:A 回答“知道了”,这样通话才算结束。
1、为什么不能把服务器发送的ACK和FIN合并起来,变成三次挥手?
因为服务器收到客户端断开连接的请求时,可能还有一些数据没有发完,这时先回复 ACK,表示接收到了断开连接的请求。等到数据发完之后再发 FIN,断开服务器到客户端的数据传送。
2、若第二次挥手时服务器的ACK没有送达客户端,会怎么样?
客户端没有收到 ACK 确认,会重新发送 FIN 请求。