“计算机网络“ 那些事

admin管理员组

文章数量:1547990

文章目录

• OSI七层和TCP/IP五层模型
• • OSI七层模型：
  • TCP/IP五层模型：
• http状态码
• 一个url请求经历了哪些过程
• • 1. URL解析
  • 2. DNS解析
  • 3. 建立TCP链接 （3次握手）
  • 4. 发送http/https请求
  • 5. 服务端响应请求
  • 6. 客户端(浏览器)解析数据，渲染页面
  • 7. 断开TCP链接 (4次挥手)
• UDP和TCP
• • UPD :
  • TCP :
  • • 1.字节流传输示意图:
    • 2.TCP报文首部信息格式:
    • 3.tcp的3次握手 - 建立链接
    • 4.tcp的4次挥手 - 断开连接
    • 5.为啥是3次握手？
    • 6.为啥是4次握手？
    • 7.tcp可靠传输
    • 8.TCP流量控制
    • 9.TCP拥塞控制
• 对称加密和非对称加密
• • 1.对称加密 : 密钥密文一起发送
  • 2.非对称加密 ：公钥加密，私钥解密
  • 3.非对称加密用于签名校验
• http和https
• • http:
  • https:
• GET和POST的区别
• 网络转发和网络代理
• CORS跨域
• • 啥是跨域?
  • 怎么解决?

本人才疏学浅，如果哪里写错了，还请大佬们多多指教～

---

参考文章：https://blog.csdn/yangbindxj/article/details/125087593

OSI七层和TCP/IP五层模型

OSI七层模型：

TCP/IP五层模型：

---

http状态码

参考：https://wwwblogs/Jinge/archive/2012/08/29/2661641.html
本人摸着胸脯保证，这个点真的经常问，有必要记一下，标红的重点记。
ps：状态码有很多，这里我只是整理一些经常会用，面试老被问的，不是全部的http状态码（全部也记不过来…）
开搞:

类别	描述	人话
1xx	服务器收到请求，客户端请继续操作	不用特殊处理
2xx	操作成功被接受并处理了	成功了
3xx	资源重定向	你要找的东西不在这里了，诺，这是新的地址，重写发请求去找
4xx	客户端请求错误	客户端发的请求不对，客户端的锅
5xx	服务器错误	服务器处理出错了，服务器的锅

状态码	英文	中文	人话
100	Continue	继续	继续搞
101	Switching Protocols	切换协议，只能切换到更新的协议	你换身新衣服
200	Ok	请求成功	nice
201	Created	成功请求并且创建了资源	收到了
202	Accepted	接受请求，但并未处理	收到了，待会处理
203	Non-Authoritative information	服务器已成功处理了请求，但返回的信息可能来自另一来源	nice, 但给你的东西可能不是你想要的
204	No Content	服务器成功处理，但未返回内容	服务器干完活了，但是啥也没给你
205	Reset Content	服务器成功处理，没有新内容，浏览器要重置文档	nice，刷新一下
300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端选择	这东西在很多地方都有, 给你列个表自己去找
301	Moved Permanently	请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替	这东西不在这里，给你个新地址，以后就去这里找
302	Found	与301类似。但资源只是临时被移动。客户端应继续使用原有URI	东西暂时不在这里，诺你去这里找，但下次继续来我这里找
303	See Other	与301类似。使用GET和POST请求查看	使用GET和POST方式再请求下
304	Not Modified	所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会访问缓存的对应资源，通过提供 If-Modified-Since 头信息指出, 客户端希望只返回在指定日期之后修改的资源	东西在你那里有, 你看看自己的缓存，等定好的时间过了，那东西要是有修改我再给你
305	Use Proxy	所请求的资源必须通过代理访问	我不和你聊，找代理来
307	Temporary Redirect	与302类似。使用GET请求重定向	东西暂时不在这里，诺你去这里找，但下次继续来我这里找，但是要用get的方式
400	Bad Request	客户端请求的语法错误，服务器无法理解	你说错了
401	Unauthorized	请求要求用户的身份认证	出示下证件
403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求(一般是权限问题)	我收到了，但是我不干活(一般是权限问题)
404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置“您所请求的资源无法找到”的个性页面	东西没了
408	Request Time-out	服务器等待客户端发送的请求时间过长，超时	你说话太慢了
413	Request Entity Too Large	由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息	你说的太多了，处理不了
414	Request-URI Too Large	请求的URI过长（URI通常为网址），服务器无法处理	你给的url太长了，处理不了
415	Unsupported Media Type	服务器无法处理请求附带的媒体格式	这种格式处理不了
500	Internal Server Error	服务器内部错误，无法完成请求	服务器的锅
501	Not Implemented	服务器不支持请求的功能，无法完成请求	你这个功能处理不了
502	Bad Gateway	充当网关或代理的服务器，从远端服务器接收到了一个无效的请求	代理的锅
503	Service Unavailable	由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中	停服维护
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求	网关干活太慢了
505	HTTP Version not supported	服务器不支持请求的HTTP协议的版本，无法完成处理	你这个版本处理不了

---

一个url请求经历了哪些过程

1. URL解析

1. URL 统一资源定位符号，用来定位互联网的资源。
2. 根据url编码规则和网络标准对url进行解析，解析成格式正确的域名。
3. 浏览器对URL进行判断

	URL是否合法
		合法：
			判断是否完整：
				不完整：
					猜测补全前缀后缀，比如www. http之类的。
		不合法：
			把URL作为搜索条件，从用户默认的搜索引擎搜索，从书签等先开始查找。

2. DNS解析

1. 检查浏览器缓存和本地hosts文件里面是否有这个域名对应的ip，如果有就从本地完成解析
2. 本地没有的话，向本地域名解析服务器系统（tcp，ip参数中设置的DNS地址）发起域名解析的请求（校园网、移动、电信或联通运营商）
3. 本地域名解析服务器还没有的话，本地域名解析服务器就：
   • 发送请求到根DNS服务器，返回顶级DNS服务器地址。
   • 再发送请求到顶级DNS服务器，返回权威DNS服务器地址。
   • 再发送请求到权威DNS服务器，返回最终ip地址。

ps：前端可以在html页面头部写入dns缓存地址

3. 建立TCP链接 （3次握手）

4. 发送http/https请求

5. 服务端响应请求

6. 客户端(浏览器)解析数据，渲染页面

7. 断开TCP链接 (4次挥手)

---

UDP和TCP

参考王道考研，计算机网络部分。

UPD :

1. UDP是无连接的，减少开销和发送数据之前的时延
2. UDP使用最大努力交付，但不保证可靠交付。
3. UDP是面向报文的，适合一次性传输少量数据的网络应用。
4. UDP无拥塞控制，适合很多实时应用。
5. UDP首部开销小，8B，TCP20B。

TCP :

1. 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的。
2. TCP提供可靠交付的服务，无差错、不丢失、不重复、按序到达。（可靠有序，不丢不重）
3. TCP是全双工通信，有发送缓存和接受缓存（每个端都可以发送和接受数据）。
4. TCP面向字节流传输，把应用层数据看成一连串无结构的字节流。

1.字节流传输示意图:

2.TCP报文首部信息格式:

• 序号：此次发送数据的第一个字节的序号。（字节流每一个字节都按顺序编号）
• 确认号：期望收到回复数据的第一个字节的序号。
• 数据偏移：真正的数据距离报文段起始位置的偏移距离。
• 紧急位URG：URG=1时，标明此报文段中有紧急数据，是高优先级的数据，应尽快传送，不用在缓存里排队，配合紧急指针字段使用。
• 确认位ACK：ACK=1时确认号有效，在连接建立后所有传送的报文段都必须把ACK置为1。
• 推送位PSH：PSH=1时，接收方尽快交付接收应用进程，不再等到缓存填满再向上交付。
• 复位RST：RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立传输链接。
• 同步位SYN：SYN=1时，表明是一个连接请求/连接接受报文。
• 终止位FIN：FIN=1时，表明此报文段发送方数据已发完，要求释放连接。
• 窗口：指的是发送本报文段的一方的接收窗口，即现在允许对方发送的数据量。（tcp每一端都有一个发送窗口和一个接受窗口，称为滑动窗口）。
• 检验和：检验首部+数据。
• 紧急指针：URG=1时才有意义，指出本报文段中紧急数据的字节数。
• 选项：最大报文段长度MSS、窗口扩大、时间戳、选择确认等等。

3.tcp的3次握手 - 建立链接

刚开始客户端和服务器都是关闭状态。

1. 第一次握手：

   • 客户端:
       发送连接请求报文，无应用层数据：
         同步位SYN=1，表示这是一个连接请求报文。
         数据序号seq=x, x表示发送的数据第一位序号，随机的，无意义。
       客户端状态由 关闭(closed) 变成 syn已发送 (syn-sent)。

   • 服务器：
       服务状态由 关闭(closed) 变成 监听 (listen)。

2. 第二次握手：

   • 服务器：
       服务器为该tcp连接分配缓存和变量。
       服务器发送确认报文给客户端, 无应用层数据：
         同步位SYN=1，表示这是一个连接接受报文。
         ACK=1, 确认号有效。
         ack=x+1, 表示服务器希望下次收到的字节序号第一位是 x+1。
         数据序号seq=y, y表示发送的数据第一位序号，随机的，无意义。
       服务状态由 监听 (listen) 变成 syn已经接受 (syn-rcvd)。

3. 第三次握手：

   • 客户端:
       客户端为该tcp连接分配缓存和变量。
       客户端发送确认报文给服务端, 可携带数据：
         同步位SYN=0。
         ACK=1, 确认号有效。
         ack=y+1, 表示客户端希望下次收到的字节序号第一位是 y+1。
         数据序号seq=x+1, x+1表示发送的数据第一位序号，就是第二次握手时候服务器希望收到的数据。

4. 3次握手完成之后，客户端和服务器的状态都变成了 确认 (estab-lished), 连接已经建立，可以进行数据传输了。

5. 3次握手可能存在的风险之一：SYN洪泛攻击。

   • 一句话总结SYN洪泛攻击 ：说一句话就不搭理你了。
   • 具体过程:
       攻击者发送第一次握手。
       服务器进行第二次握手。
       攻击者不进行第三次握手。
       这样的话这个TCP连接就会被挂起，处于半连接状态。
       攻击者进行大量的第一次握手，就会造成服务器有大量的TCP连接被挂起，消耗服务器的CPU和内存资源。
   • 解决办法：
       1.降低SYN timeout时间，使服务器尽快释放半连接状态的TCP。
       2.使用SYN cookie：
         第一次握手服务器不会为该报文段生成一个半开连接。
         服务器使用客户端的ip和port生成一个TCP序列号，也就是 cookie. 发送给客户端
         服务器通过客户端发过来的cookie进行校验该连接是否合法。

4.tcp的4次挥手 - 断开连接

1. 第一次挥手：
   • 客户端:
       发送连接释放报文：
         结束位FIN=1，表示这是一个连接释放报文。
         数据序号seq=u, u是客户端已经传送数据的最后一位序号+1。
       客户端状态由 确认 (estab-lished) 变成 等待结束-1 (FIN-wait-1)。
2. 第二次挥手：
   • 服务端:
       发送确认报文：
         ACK=1, 确认号有效。
         ack=u+1, 表示服务端希望下次收到的字节序号第一位是u+1。
         数据序号seq=v, v表示服务端已经发送的数据的最后一位是 v-1。
       服务端状态由 确认 (estab-lished) 变成 等待关闭 (close-wait)。
3. 第三次挥手：
   • 服务端:
       发送连接释放报文：
         结束位FIN=1，表示这是一个连接释放报文。
         ACK=1, 确认号有效。
         ack=u+1, 表示服务端希望下次收到的字节序号第一位是u+1。
         数据序号seq=w, w表示服务端第二次挥手之后发送的最后一个字节序号是 w-1。
       服务端状态由 等待关闭 (close-wait) 变成 最后确认 (last-ack)。
   • 客户端:
       客户端状态由 等待结束-1 (FIN-wait-1) 变成 等待结束-2 (FIN-wait-2)。
4. 第四次挥手：
   • 客户端:
       发送确认报文：
         ACK=1, 确认号有效。
         ack=w+1, 表示客户端希望下次收到的字节序号第一位是W+1。
         数据序号seq=u+1。
       客户端状态由 等待结束-2 (FIN-wait-2) 变成 倒计时 (time-wait)。
       客户端倒计时等待2MSL后，链接彻底关闭，状态由 倒计时 (time-wait) 变成 关闭 (closed)。
       为什么要等待2MSL? 确认客户端的最后的ACK包成功到达。
         因为在等待之前，客户端发了一个ACK，需要在这2MSL时间内看看服务端会不会让客户端重发，确认包到达了才能断开。
   • 服务端:
       服务端状态由 最后确认 (last-ack) 变成 关闭 (closed)。

5.为啥是3次握手？

一句话总结：少于2次无法保证数据传输，多于3次没必要。

• 2次握手的话，发送方可以确定自己能发能收，但是接收方只知道自己可以接收，但不确定自己是否可以发送。
• 2次握手的话，如果网络延迟阻塞了，一个数据可能会发送多个请求，造成了多个tcp连接，浪费资源。

6.为啥是4次握手？

一句话总结：少于4次无法保证服务器数据完全发送完成，多于4次没必要。
因为：
  客户端主动要求断开后，服务器先回复确认，
  然后在所有数据发送完成之后，再发送FIN=1的报文段（第三次挥手）
  最后才能关闭，保证数据传输完成。

7.tcp可靠传输

可靠传输：发送和收到的数据是一模一样的。
如何实现可靠传输？
  1. 首部校验。
  2. 序号确认机制：tcp数据都是有序号的，只有对端回复了确认收到的报文，发送方才会把数据从发送缓存中移除。
  3. 超时重传：TCP采用动态改变重传时间RTTS，发送方在规定时间(RTTs)内没有收到确认报文，就重新发送。
  4. 冗余ACK确认, 例如 :
    发送方发送 1, 2, 3, 4, 5，这个5个报文段.
    接收方收到1，返回冗余ACK为 “我已经收到了1”。这时候报文段 2 丢失了。
    接收方收到3, 返回冗余ACK为 “我已经收到了1”。
    发送方已经把3都发出去了，但是收到的消息任然是 “我已经收到了1”, 所以认为2已经丢失，就重传。

8.TCP流量控制

流量控制 : 你发慢点，我接收不过来了。
TCP利用滑动窗口机制实现流量控制：
1.接收方把自己的接收窗口大小-win的数量，放入tcp头部"窗口大小"字段中，传输给发送方。
2.发送方根据接收方的接收窗口大小，来调整发送的速度。
3.接收方系统会开辟一个缓冲区，用来记录哪些数据还没有处理应答，只有处理应答了才会从接口窗口(缓存)中删除。

9.TCP拥塞控制

拥塞控制 : 避免过多的数据进入网络。
流量控制只是控制一个设备的数据，拥塞控制是控制全局网络的数据。
拥塞控制的方法：

• 慢开始和拥塞避免
  
  1.慢启动 : 经过一个RTT(请求往返时间), 运算窗口进行一次指数级增加。
  2.如果窗口数量超过慢启动的上限值(16)，窗口进行拥塞避免阶段，停止指数级增长，使用加法增长。
  3.加法增长到了网络拥塞(24), 窗口直接变成1，重新一次慢启动。
  4.但是这个时候慢启动的上限值只有上一次网络拥塞时的数量的一半。
  问题 ：遇到网络拥塞时候，直接把窗口干到1个，会导致传输速率大大降低，所以该算法优化后变成 - 快重传和快恢复

• 快重传和快恢复
  
  1.刚开始的也是和之前一样的流程。
  2.当收到3个重复的ACK，表示有包丢了，也就是遇到了网络拥塞，把窗口大小调整为一半。
  3.然后重传ACK需要的包。
  4.然后进入拥塞避免，窗口使用加法增长的阶段。

---

对称加密和非对称加密

参考 ：https://juejin/post/7036551179517558791

1.对称加密 : 密钥密文一起发送

1. 发送方使用 密钥Y 与 加/解密算法fn 对原始数据进行加密 得到 加密报文X。
2. 发送方把 密钥Y 与 加密报文X 一起进行发送。(接收方需要知道密钥才能解密)。
3. 接收方把 加密报文X 与 密钥Y 用 加/解密算法fn 进行解密，得到原始数据。

问题来了，由于加/解密算法fn是公开的，也就那么几种，所以黑客只需要把密钥Y 和加密报文X一起撸下来，就可以解密数据了啊，所以http是不安全的。

优点：高效，适用于大量数据的加密。
缺点：加解密算法公开，只要得到key，就可以解密数据，不安全。

2.非对称加密 ：公钥加密，私钥解密

1.接收方生成一对匹配的 公钥 和 私钥。
2.私钥自己装好，公钥向外界公布。
3.发送方拿到接收方的公钥 ，使用接收方的公钥加密数据，接收方使用自己的私钥解密数据。

优点：安全性高。
缺点：加解密复杂，效率低。

---

3.非对称加密用于签名校验

问题，我拿到你给的一个数据，我怎么知道这个数据一定是你给的呢？
1.你把数据"hello" 用SHA256进行hash计算，得到明文的hash值。
2.然后使用私钥对 明文的hash值 进行加密, 得到hash值的密文(密钥签名)。
3.接着把数据"hello"和hash值的密文(密钥签名)一起发送给我。
4.我用你的公钥解密hash值的密文(密钥签名)，得到 明文的hash值。
5.我再对数据"hello"用SHA256进行hash计算，得到明文的hash值。
6.最后我对两个明文的hash值进行比对，相同则说明是你发的数据，不同则不是你发的。
(因为hash值的密文(密钥签名)是用你的私钥进行加密的，所以如果用你的公钥能解密出来数据，则这个数据必然是你发的)

ps : 上图的密钥是指私钥

---

http和https

参考 ：https://juejin/post/7036551179517558791

http:

1. http超文本传输协议，是一个请求与响应，无状态的应用层协议。

2. 基于tcp/IP协议传输数据。

3. 端口是80.

4. HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

5. 无链接：一次请求和响应之后断开连接，但如果头部信息设置 Connection : keep-alive，可以保持连接状态。

6. 请求数据明文传输，保密性差。

7. 请求报文：

   • 起始行（start line）：描述请求或响应的基本信息；
   • 头部字段（header）：使用 key-value 形式更详细地说明报文；
   • 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

   其中起始行和头部字段并成为 请求头 或者 响应头，统称为 Header；
   消息正文也叫做实体，称为 body。
   HTTP 协议规定每次发送的报文必须要有 Header，但是可以没有 body，也就是说头信息是必须的，实体信息可以没有。
   

8. 响应报文：
   

9. 版本信息：

版本	内容	现状
http/0.9	不能进行数据包传输，只有get请求	没有使用
http/1.0	传输内容格式不限制，增加了post，put，delete等方法	开始使用
http/1.1	支持持久连接，host域，管道机制，分块传输	广泛使用
http/2	多路复用(一个请求可以有多个响应)，头信息压缩，二进制协议等	广泛使用

https:

通过SSL或TLS提供加密处理数据，身份验证和数据完整性保护。

1.内容加密：采用混合加密技术，中间者无法直接查看明文内容.
2.验证身份：通过证书认证客户端访问的是自己的服务器.
3.保护数据完整性：防止传输的内容被中间人冒充或者篡改.
4.端口443.

问题1：
  中间人攻击：黑客可以把服务器的公钥，改成自己的公钥发给客户端，那么截取客户端的数据，就可以用自己的私钥解密了。
  解决办法：客户端通过证书认证机构验证服务器的公钥是否合法。
   比如去学信网 (证书) 查一下你的学历 (公钥) 是否合法。
   认证机构是大家都相信的，全世界就那么几个, 但有分公司。

问题2 :
  对数据进行非对称加密，效率太低。
  解决办法：
    1.客户端生成自己的对称加密密钥key : 会话密钥
    2.对数据进行对称加密。
    3.对会话密钥使用非对称加密，即使用服务器的公钥加密, 得到加密后的会话密钥。
    4.然后把 加密后的会话密钥 和 对称加密后的数据 一起发给服务器。
    5.服务端使用私钥解密加密后的会话密钥 得到解密数据的会话密钥。
    6.服务端使用会话密钥 解密数据。

5.一次https链接结束后，客户端清除会话密钥，下次又重新创建。

---

GET和POST的区别

GET :
 1. 请求的数据会附在 URL 之后（放在请求行中），以 ? 分割 URL 和传输数据，多个参数用 & 连接。
 2. 用于信息获取。
 3. 请求行是这样：GET /search/users?q=xxxxx HTTP/1.1。
 4. 会被浏览器主动缓存的，如果下一次传输的数据相同，那么就会返回缓存中的内容，以求更快地展示数据。
 5. URL 一般都具有长度限制（http协议不限制，浏览器和具体的服务器做限制，不同的浏览器和不同的服务器有所不同）。
 6. 只产生一个 TCP 数据包，把请求头和请求数据一并发送出去，服务器响应 200 ok(返回数据)。

POST :
 1. 用于给服务器提交数据。
 2. 请求行是：POST / HTTP/1.1, 可以没有URL。
 3. 请求数据是放在请求体body中，请求数据没有长度限制。
 4. POST 方法会产生两个 TCP 数据包，浏览器会先将请求头发送给服务器，待服务器响应100 continue，浏览器再发送请求数据，服务器响应200 ok(返回数据)。这么看起来 GET 请求的传输会比 POST 快上一些（因为GET 方法只发送一个 TCP 数据包），但是实际上在网络良好的情况下它们的传输速度基本相同。

注意：
 1.get和post的本质是一样的，都是基于TCP/IP协议的http请求。
 2.在技术上完全可以给 POST 加上URL参数，给 GET 加上请求数据，但是强烈不建议这么搞。
 3.为什么要区分：1.语意化，2.方便管理。

---

网络转发和网络代理

• 网络转发 : 客户端直接请求目标服务器，中间路由器对报文进行转发。
• 网络代理 : 本身就是一个服务，客户端请求代理服务器，代理服务器再去请求真正的服务器，收到数据之后回复给客户端。

1.正向代理：一种客户端的代理技术，帮助客户端访问无法访问的服务器资源，可以隐藏用户真实IP，比如 VPN。

• 接收客户端请求
• 根据请求数据做一些配置
• 复制请求到发送到真正的服务器
• 接收服务器返回数据
• 对返回数据做一些处理，返回客户端
  
  2.反向代理：一种服务器的代理技术，帮助服务器做负载均衡，缓存，安全校验等，可以隐藏服务器真实IP，比如 nginx。
• 接收客户端请求，根据需求修改请求结构信息。
• 通过负载均衡算法把请求发到对应的服务。
• 得到数据，处理数据，返回数据给客户端。
  

---

CORS跨域

啥是跨域?

跨域是由于浏览器和服务器之间同源策略, 也就是 协议，域名，端口号不对应产生的。
比如 浏览器是 http://111.22.33:8080, 服务器是 http://111.22.33.9090，这时候就会产生跨域问题，服务器收到请求也返回了，但是浏览器拿到数据之后，看了http请求头中的相关信息，就知道端口不一致，就报错不显示数据了。

怎么解决?

1. 服务器中间件里面，这是http请求头，解决跨域. (常用的方案)
2. 反向代理服务器设置 (例如: nginx)，把port改成和浏览器一样

本文标签： 计算机网络