计算机网络复习笔记

本文结合计算机网络自顶向下，中科大郑烇老师网课，b 站 up 主湖科大教书匠(讲的太好了)以及优秀的博客(CS-Notes)和公众号进行总结，从问题出发，同时不破坏计算机网络得整体结结构，对问题分类总结，方便记忆

文章目录

• 1.计算机网络分层模型
• • 1.1计算机分层模型⭐️
  • • 五层协议
• 2 传输层(TCP)
• • 2.1 TCP 和 UDP 的区别⭐️
  • 2.2 TCP 头部格式⭐️
  • 2.3 三次握手四次挥手⭐️
  • • 2.3.1 三次握手细节⭐️
    • 2.3.2 为什么不能两次握手呢⭐️
    • 2.3.3 TCP 四次挥手⭐️
    • 2.3.4 TCP 为什么要四次挥手⭐️
    • 2.3.5 简述 TIME_WAIT和 CLOSE_WAIT⭐️
  • 2.4 TCP 协议如何保证传输的可靠性
  • • 2.4.1超时重传(ARQ)
    • 2.4.2确认应答号和序列号
    • 2.4.3三次握手四次挥手
    • 2.4.4 流量控制
    • 2.4.5 拥塞控制
    • • 2.4.5.1慢开始和拥塞避免算法
      • 2.4.5.2 快重传和快恢复
      • 2.4.5.3 改进的整体算法
• 3 传输层(HTTP)
• • 3.1 HTTP 报文结构和状态码
  • 3.2 GET 和 POST方法
  • 3.3HTTP是不保存状态的协议,如何保存用户状态?
  • 3.4Cookie的作用是什么?和Session有什么区别？
  • 3.5 输入一个网址发生的事情

1.计算机网络分层模型

1.1计算机分层模型⭐️

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bhaffciJ-1620353895627)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-04-29 11.12.07.png)]

• 五层协议

  • 应用层 ：为特定应用程序提供数据传输服务，例如 HTTP、DNS 等协议。应用程序之间的交互数据单位为报文。
  • 传输层 ：为两台主机进程提供通用数据传输服务。运输层包括两种协议：传输控制协议 TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段；用户数据报协议 UDP，提供无连接、尽最大努力的数据传输服务，数据单位为用户数据报。TCP 主要提供完整性服务，UDP 主要提供及时性服务。
  • 网络层 ：网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。(路由)
  • 数据链路层 提供链路层协议为同一链路的主机提供数据传输服务。（交换机）
  • 物理层 ：考虑如何在传输介质上传输数据流，使数据链路层感觉不到不同的传输介质和传输手段的差异对它造成的影响

  报文，报文段，分组，包，数据报、帧、数据流

2 传输层(TCP)

2.1 TCP 和 UDP 的区别⭐️

2.2 TCP 头部格式⭐️

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DzapVBnf-1620353895628)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-04-29 18.55.44.png)]

• 源端口和目的端口号：表明该报文段来自的应用进程，以及要去向哪个进程

• 序号：TCP 报文段的数据载荷的第一个字节的序号

• 确认号：期望收到的下一个 TCP报文段的数据载荷的第一个字节的序号，也是对之前收到的数据的确认。(如果确认号 = n，则表明序号为 n - 1的所有的数据已经正确接收，期望接收序号为 n 的数据)

• ACK：ACK 确认号字段为1时，确认字段有效，0则无效。TCP建立连接后所有的字段都必须把 ACK 设置为1.

• 数据偏移：用来指出 TCP 报文段的数据载荷离TCP 报文段的开头有多远

• SYN(Synchronize Sequence Numbers)：TCP建立时来同步序号

• FIN(FInish):用来释放连接

2.3 三次握手四次挥手⭐️

seq：seq = ack(对方的的期望下一次的序号) ack = seq + 1(对方的序列号加一)

2.3.1 三次握手细节⭐️

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ugVPQFdf-1620353895629)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-01 16.55.49.png)]

答题思路：对该图进行描述

2.3.2 为什么不能两次握手呢⭐️

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sr8blMIE-1620353895629)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-01 17.05.20.png)]

答题思路：是因为为了防止已经失效的 TCP 客户端连接请求又传送到了服务器端，造成资源浪费，然后进行上图的木描述。

2.3.3 TCP 四次挥手⭐️

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qAUYXp3T-1620353895630)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-03 10.32.47.png)]

答题思路：按照图片描述，注意 各种数值

2.3.4 TCP 为什么要四次挥手⭐️

​ 因为 TCP 服务器端可能还有一 些报文段需要发送，所以对于客户端的请求关闭连接只能先回复，你的 FIN我收到了，但是我还有一些数据要发送你等我发送完之后，我再给你发送关闭请求。

2.3.5 简述 TIME_WAIT和 CLOSE_WAIT⭐️

​ 描述：客户端收到服务器端的 FIN 请求的时候进入这个状态，此时客户端并不是直接关闭进入 CLOSE 状态，而是再保持一个2MSL 再进入 CLOSED 状态。

​ 原因：

​ 1. 确认服务器端能够收到客户端的确认报文，万一没有收到，就会重新发送，而此时客户端已经关闭，那么服务器端就会造成资源浪费，无法关闭

​ 2.使本次连接内的所有报文段都消失，下一次的连接内不会出现这一次的报文段。

2.4 TCP 协议如何保证传输的可靠性

2.4.1超时重传(ARQ)

发送发没有收到 ACK 那么会进行重新发送

2.4.2确认应答号和序列号

2.4.3三次握手四次挥手

2.4.4 流量控制

​ TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据

2.4.5 拥塞控制

• 当我们对网络的吞吐量超过了目前网络所能提供的吞吐量那么网络性能可能就会变坏

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8SSiaAlB-1620353895631)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-03 14.54.10.png)]

2.4.5.1慢开始和拥塞避免算法

• 慢开始

  1. 目的：用来确定网络的负载能力

  2. 思路：从小到大增加拥塞窗口的数值

  3. 两个变量：

     ​ 拥塞窗口（cwnd）初始拥塞窗口值

     ​ 慢开始门限（ssthresh）：防止拥塞窗口增长过大引 起网络拥塞。

• 拥塞避免

  1. 思路：让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞。

  2. 每经过一个传输轮次，拥塞窗口 cwnd = cwnd + 1

     [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kCjqrR8u-1620353895631)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-03 15.17.10.png)]

2.4.5.2 快重传和快恢复

• 快重传：发送方一旦收到接收方的三个连续的重复确认，就立即重传，而不是等到重传计时器超时再重传，这样避免了有个别报文段丢失，之前的算法却误以为发生了网络拥塞，降低了效率。

• 快恢复：发送方一旦收到接收方的三个连续的重复确认，就启动快恢复算法而不是慢开始算法。

2.4.5.3 改进的整体算法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-47sxJ2g4-1620353895631)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-05-03 15.39.09.png)]

3 传输层(HTTP)

3.1 HTTP 报文结构和状态码

请求报文结构：

• 第一行是包含了请求方法、URL、协议版本；
• 接下来的多行都是请求首部 Header，每个首部都有一个首部名称，以及对应的值。
• 一个空行用来分隔首部和内容主体 Body
• 最后是请求的内容主体

GET http://www.example.com/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cache-Control: max-age=0
Host: www.example.com
If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT
If-None-Match: "3147526947+gzip"
Proxy-Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 xxx

param1=1&param2=2

响应报文结构：

• 第一行包含协议版本、状态码以及描述，最常见的是 200 OK 表示请求成功了
• 接下来多行也是首部内容
• 一个空行分隔首部和内容主体
• 最后是响应的内容主体

HTTP/1.1 200 OK
Age: 529651
Cache-Control: max-age=604800
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 648
Content-Type: text/html; charset=UTF-8
Date: Mon, 02 Nov 2020 17:53:39 GMT
Etag: "3147526947+ident+gzip"
Expires: Mon, 09 Nov 2020 17:53:39 GMT
Keep-Alive: timeout=4
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Proxy-Connection: keep-alive
Server: ECS (sjc/16DF)
Vary: Accept-Encoding
X-Cache: HIT

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
	// 省略... 
</body>
</html>

状态码：

• 200 OK

• 301 Moved Permanently ：永久性重定向

• 302 Found ：临时性重定向

• 400 Bad Request ：请求报文中存在语法错误。

• 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。

• 403 Forbidden ：请求被拒绝。

• 404 Not Found：输入了错误的 URL

• 500 Internal Server Error ：服务器正在执行请求时发生错误。

• 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

3.2 GET 和 POST方法

3.3HTTP是不保存状态的协议,如何保存用户状态?

​ HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了

3.4Cookie的作用是什么?和Session有什么区别？

cookie：是服务器发送到用户浏览器并且保存在本地的一块小数据，它会在浏览器之后向同一服务器再次发送请求时携带上，用来告知服务器端两个请求是否来自于同一个浏览器(服务员给的小卡片)

1. 浏览器第一次访问服务器，服务器为它创建一个身份，格式为 key - value，内容放入 set-cookie 字段里面
2. 浏览器看到这个字段就会保存下来，然后下次的时候就会放在 cookie 字段里面发送到服务器端
3. 服务器端收到这个请求报文后，相当于身份的识别，就会为它提供个性化的服务

session：存储在服务器端，更加安全。过程是借用了 cookie 的传输机制

1. 客户进行登录，浏览器进行验证账户和密码，通过之后，信息存储再 redis 里面，然后里面有一个 session id
2. 服务器返回的相响应报文内包含了这个 session id，客户端收到响应报文后将 cookie 存入浏览器
3. 下一次访问时候携带上 sessionid，就可以继续进行操作

3.5 输入一个网址发生的事情