一文读懂计算机底层网络原理，包括TCP、UDP、header，什么是包、帧、段等关键问题

 

 

说到计算机网络原理，大家可能马上联想到，七层协议，传输层，链路层，三次握手四次挥手；前端的同学，还会想到我们用Crome F12的network里面的headers，状态码等。后端同学可能会联想到，抓包，路由网关等。你们联想到什么关键字，欢迎留言哟！

那么，我们来提出几个问题：

  1. 七层协议之间是如何传输的？什么是包、帧、段？
  2. TCP/IP协议是什么？TCP和UPD有什么区别？
  3. 什么是三次握手四次挥手？为什么要握手和挥手？
  4. 浏览器network的HTTP headers 和 TCP headers有什么区别？

下面，我们就一一回答上面的问题。

七层协议之间是如何传输的？什么是包、帧、段？

 

看上图，所以数据、段、包、帧、比特，讲的其实都是一个东西，只是由于所在的位置不同，作为专有名词的名字不同。

  • 我们先看一下最上层的数据，Data是应用层协议产生的数据，例如访问网页、看视频、听音乐，这些都可以称为应用层数据，电脑的操作系统会把这些应用层数据按照一定的规则传给下一层传输层。

  • 在传输层，我们看到的数据称之为Segment，中文意思是段。在这一层，数据会被加上TCP或者UDP头，变成一个应用程序特有的数据。操作系统就是通过TCP或UDP端口号来区别不同应用程序的。

  • 当数据再被往下传输的时候，就变成了packet，即“包”的意思。在这一层，Segment会被加上IP头部信息，然后就可以在三层传输了，而工作在三层的路由器会根据目的IP地址来转发这些”包“。

  • 在往下，数据就会被加上MAC地址信息，名称就变成了Frame，”帧“。在这一层，就是交换机的世界了，交换机通常查找MAC地址表项来转发相应的”帧“。

上面的几个层次都可以使用wireshark抓包查看到具体的内容，比较形象，例如下面，一层套着一层，明显可以看出帧、包、段、数据的区别。

那么，不同层之间，是如何通信的呢？

很多人讲到七层协议传输，会想到教材下图左，可是这七层是如何一层层互相构成的，更符合大脑感官的是另一种认知形式，是一种洋葱形的结构，层层叠叠互相包裹，可以用下图表示：

一层一层传输，加上图一对应的头部信息，或者mac地址，进行封装，传给下一层。具体的也可以看上图抓包信息。每一层的数据，内容不同，叫不同的名字。

再往下面的物理层（layer1），我们能看到的都是BIT流，它们呈现给我们的都是0和1这样的电气特性。他们将数字信号转化为物理信号，bits 转化为光信号。网络延时，一般在这一层，考虑传输距离和光速，光纤管道拥塞，包等待，TCP 做 Flow Control（流控），转化速率等，平常只有那些头发比较稀少的硬件工程师才关注，咱们一般看不到。工作中我们看到网络设备的物理层都已经是非常成熟的内容，一般不会有问题。

 

 

各位看到这里，应该能够明白“帧”和“包"区别了吧？其实很多的时候它们就是通用的，只是它们所在的网络层次不同，封装也不同。为了显示专业，一般我们在讨论交换机相关的layer2内容时，可以把数据称之为”帧“，在讨论与路由器相关的layer3内容时，就把数据称之为”包“。他们是如何传输的，以上也做了解答。

TCP/IP协议是什么？TCP和UPD有什么区别？

计算机硬件通过网络通信，双方就要基于相同的方法。比如，如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信，所有的这一切都需要一种规则。而我们就把这种规则称为协议（protocol）。

TCP/IP 是互联网相关的各类协议族的总称，比如：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都属于 TCP/IP 族内的协议。

TCP/IP模型是互联网的基础，它是一系列网络协议的总称。这些协议可以划分为四层，分别为链路层、网络层、传输层和应用层。

也就是每一层都有自己的协议，我们前端在浏览器调试的是最上层——应用层的HTTP协议，属于TCP/IP协议的一种。 具体看下图：

  • 应用层：负责向用户提供应用程序，比如HTTP、FTP、Telnet、DNS、SMTP等。
  • 传输层：负责对报文进行分组和重组，并以TCP或UDP协议格式封装报文。
  • 网络层：负责路由以及把分组报文发送给目标网络或主机。
  • 链路层：负责封装和解封装IP报文，发送和接受ARP/RARP报文等。

传输层协议里面有UDP和TCP协议，我们来看看他们具体区别和应用场景。

UDP和TCP协议区别（广播，一对一）

 如上图：

TCP向上层提供面向连接的可靠服务 ，UDP向上层提供无连接不可靠服务。 虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为 对数据准确性要求高，速度可以相对较慢的，可以选用TCP 我们在第一部分，说明了，从应用层到传输层，会加上UDP/TCP头，那什么情况加UDP头，什么情况加UDP头呢？以下分别进行说明：

UDP

UDP协议全称是用户数据报协议，在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。

它有以下几个特点：

  1. 面向无连接

首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。

具体来说就是： 在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了。 在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作。

  1. 有单播，多播，广播的功能

UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。

  1. UDP是面向报文的

发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文。

  1. 不可靠性

首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠。

并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。

再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。

 

 

12.gif 从上面的动态图可以得知，UDP只会把想发的数据报文一股脑的丢给对方，并不在意数据有无安全完整到达。

  1. 头部开销小，传输数据报文时是很高效的。

 UDP 头部包含了以下几个数据：

  • 两个十六位的端口号，分别为源端口（可选字段）和目标端口
  • 整个数据报文的长度
  • 整个数据报文的检验和（IPv4 可选 字段），该字段用于发现头部信息和数据中的错误

因此 UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的。

TCP

当一台计算机想要与另一台计算机通讯时，两台计算机之间的通信需要畅通且可靠，这样才能保证正确收发数据。对比上面的UDP，就知道为啥要握手和挥手了，目的就是为了保证可靠的连接。平时TCP用的场景更多。

TCP协议全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的RFC 793定义。流就是指不间断的数据结构，你可以把它想象成排水管中的水流。

  1. tcp连接过程，建立连接，三次握手。为啥握手挥手？基于安全考虑，确认连接对象（面向连接）和其状态（可靠传输）

第一次握手 客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。

第二次握手 服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。

第三次握手 当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入ESTABLISHED 状态，服务端收到这个应答后也进入ESTABLISHED状态，此时连接建立成功。

这里可能大家会有个疑惑：为什么 TCP建立连接需要三次握手，而不是两次？这是因为这是为了防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误。

 

2.断开连接，四次挥手

TCP是全双工的，在断开连接时两端都需要发送 FIN 和 ACK，2*2就是4次啦。

第一次挥手 若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。

第二次挥手 B 收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明 A 到 B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。

第三次挥手 B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态。

第四次挥手 A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。

所以，TCP协议的特点：

1.面向连接

面向连接，是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”，这样能建立可靠的连接。建立连接，是为数据的可靠传输打下了基础。

2.仅支持单播传输

每条TCP传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播传输方式。

3.面向字节流

TCP不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。

4.可靠传输

对于可靠传输，判断丢包，误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。

5.提供拥塞控制

当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞

6.TCP提供全双工通信

TCP允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）

7.TCP头部

一个 TCP Header 一般有 20 个字节，如果启用了 options，header的长度可以达到 60 个字节。 内容包含：

  • 发送方端口号和接收方的端口号
  • 发送方的序列号
  • 接收方 ack 的序列号
  • 从 CWR 到 FIN 的 8 个 bit
  • ACK 和 SYN
  • 校验

详细内容，可以到网上搜，不赘述。总之，里面包含了三次握手和四次挥手的内容，以及端口号校验码等，来确认两台机器的可靠连接。

浏览器network的HTTP headers 和 TCP headers有什么区别？

我们上面说了这么多，大概知道了HTTP headers 和 TCP headers的区别，http是应用层的协议，tcp是传输层可靠连接协议，tcp/ip是协议族总称，不仅包含tcp和http，还包含所有七层用到的所有协议。

HTTP协议用于客户端和服务器端之间的通信。

HTTP协议和TCP/IP协议族内的其他众多的协议相同， 用于客户端和服务器之间的通信。请求访问文本或图像等资源的一端称为客户端， 而提供资源响应的一端称为服务器端。在两台计算机之间使用HTTP协议通信时， 在一条通信线路上必定有一端是客户端， 另一端则是服务器端。

有时候， 按实际情况， 两台计算机作为客户端和服务器端的角色有可能会互换。 但就仅从一条通信路线来说， 服务器端和客户端的角色是确定的， 而用HTTP协议能够明确区分哪端是客户端， 哪端是服务器端。

HTTP协议规定， 请求从客户端发出， 最后服务器端响应该请求并返回。

换句话说， 肯定是先从客户端开始建立通信的， 服务器端在没有接收到请求之前不会发送响应。

HTTP是一种不保存状态， 即无状态（stateless） 协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。 也就是说在HTTP这个级别， 协议对于发送过的请求或响应都不做持久化处理。

现在我们来了解一下HTTP headers内容

  上图从上到下解析：

  1. 请求地址  
  2. get表示请求访问服务器的类型， 称为方法（method），还有post
  3. status code 服务器返回状态码
  4. 其他的看下表

前端用的多的主要是这些，还有根据方法不同的各种传参方式，转json格式，body等

GET和POST区别
GET后退按钮/刷新无害，POST数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
GET书签可收藏，POST为书签不可收藏。
GET能被缓存，POST不能缓存 。
GET编码类型application/x-www-form-url，POST编码类型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
GET历史参数保留在浏览器历史中。POST参数不会保存在浏览器历史中。
GET对数据长度有限制，当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。POST无限制。
GET只允许 ASCII 字符。POST没有限制。也允许二进制数据。
与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET ！POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
GET的数据在 URL 中对所有人都是可见的。POST的数据不会显示在 URL 中。

请求首部字段（Request Header Fields）：从客户端向服务器端发送请求报文时使用的首部。 补充了请求的附加内容、 客户端信息、 响应内容相关优先级等信息。

响应首部字段（Response Header Fields）：从服务器端向客户端返回响应报文时使用的首部。 补充了响应的附加内容， 也会要求客户端附加额外的内容信息。

 

实体首部字段（Entity Header Fields）：针对请求报文和响应报文的实体部分使用的首部。 补充了资源内容更新时间等与实体有关的信息。 这些也是我们跟后端交互，调用接口的关键信息

请求方法： I

状态码

状态码分类表

类别 原因短语
1xx Informational（信息性状态码） 接受的请求正在处理
2xx Success（成功状态码） 请求正常处理完毕
3xx Redirection（重定向） 需要进行附加操作以完成请求
4xx Client error（客户端错误） 客户端请求出错，服务器无法处理请求
5xx Server Error（服务器错误） 服务器处理请求出错

 

1xx消息

这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送1xx响应。 这些状态码代表的响应都是信息性的，标示客户应该采取的其他行动。

  • 100 - 客户端应当继续发送请求
  • 101 - 切换协议
  • 102 - 处理将被继续执行

2xx成功

这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

  • 200 - （成功）请求已成功，请求所希望的响应头或数据体将随此响应返回。
  • 201 - （已创建）请求成功且服务器已创建了新的资源。。
  • 202 - （已接受）服务器已接受了请求，但尚未对其进行处理。
  • 203 - （非授权信息）服务器已成功处理了请求，但返回了可能来自另一来源的信息。
  • 204 - （无内容）服务器成功处理了请求，但未返回任何内容。
  • 205 - （重置内容）服务器成功处理了请求，但未返回任何内容。
  • 206 - （部分内容）服务器成功处理了部分 GET 请求。

3xx重定向

这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明。按照HTTP/1.0版规范的建议，浏览器不应自动访问超过5次的重定向。对重定向一般是由浏览器来控制重定向的次数，重定向会导致客户端不必要的资源消耗

  • 300 - 多重选择，被请求的资源有一系列可供选择的回馈信息。
  • 301 - 永久移除，被请求的资源已永久移动到新位置。
  • 302 - 临时移动，请求的资源现在临时从不同的URI响应请求。
  • 303 - 查看其他位置，对应当前请求的响应可以在另一个URI上被找到，而且客户端应当采用GET的方式访问那个资源。
  • 304 - 未修改。自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。
  • 305 - 使用代理，被请求的资源必须通过指定的代理才能被访问。
  • 306 - 临时重定向，在最新版的规范中，306状态码已经不再被使用。
  • 307 - 临时重定向。

4xx客户端错误

这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。

  • 400 - 错误的请求。
  • 401 - 访问被拒绝。
  • 402 - 付款要求。
  • 403 - 禁止访问
    • 403.1 - 执行访问被禁止。
    • 403.2 - 读访问被禁止。
    • 403.3 - 写访问被禁止。
    • 403.4 - 要求 SSL。
    • 403.5 - 要求 SSL 128。
    • 403.6 - IP 地址被拒绝。
    • 403.7 - 要求客户端证书。
    • 403.8 - 站点访问被拒绝。
    • 403.9 - 用户数过多。
    • 403.10 - 配置无效。
    • 403.11 - 密码更改。
    • 403.12 - 拒绝访问映射表。
    • 403.13 - 客户端证书被吊销。
    • 403.14 - 拒绝目录列表。
    • 403.15 - 超出客户端访问许可。
    • 403.16 - 客户端证书不受信任或无效。
    • 403.17 - 客户端证书已过期或尚未生效。
    • 403.18 - 在当前的应用程序池中不能执行所请求的 URL。
    • 403.19 - 不能为这个应用程序池中的客户端执行 CGI。
    • 403.20 - Passport 登录失败。
  • 404 - 未找到。
    • 404.0 -（无） – 没有找到文件或目录。
    • 404.1 - 无法在所请求的端口上访问 Web 站点。
    • 404.2 - Web 服务扩展锁定策略阻止本请求。
    • 404.3 - MIME 映射策略阻止本请求。
  • 405 - 用来访问本页面的 HTTP 谓词不被允许（方法不被允许）
  • 406 - 客户端浏览器不接受所请求页面的 MIME 类型。
  • 407 - 要求进行代理身份验证。
  • 408 - 请求超时。
  • 409 - 由于和被请求的资源的当前状态之间存在冲突，请求无法完成。
  • 410 - 被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。
  • 411 - 服务器拒绝在没有定义Content-Length头的情况下接受请求。
  • 412 - 前提条件失败。
  • 413 – 请求实体太大。
  • 414 - 请求 URI 太长。
  • 415 – 不支持的媒体类型。
  • 416 – 所请求的范围无法满足。
  • 417 – 执行失败。
  • 418 – 本操作码是在1998年作为IETF的传统愚人节笑话。
  • 421 – 从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。
  • 422 – 请求格式正确，但是由于含有语义错误，无法响应。
  • 423 – 当前资源被锁定。
  • 424 – 由于之前的某个请求发生的错误，导致当前请求失败。
  • 425 – 无序的集合。
  • 426 – 客户端应当切换到TLS/1.0。
  • 451 – （由IETF在2015核准后新增加）该访问因法律的要求而被拒绝。

5xx服务器错误

这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。

  • 500 - 内部服务器错误。
  • 501 - 尚未实施，页眉值指定了未实现的配置。
  • 502 - 错误网关，Web 服务器用作网关或代理服务器时收到了无效响应。
  • 503 - 服务不可用，这个错误代码为 IIS 6.0 所专用。
  • 504 - 网关超时，服务器作为网关或代理，未及时从上游服务器接收请求。
  • 505 - HTTP 版本不受支持，服务器不支持请求中所使用的 HTTP 协议版本。
  • 506 - 服务器没有正确配置。
  • 507 - 存储空间不足。服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。
  • 509 - 带宽超过限制。这不是一个官方的状态码，但是仍被广泛使用。
  • 510 - 没有扩展，获取资源所需要的策略并没有被满足。
posted @ 2021-04-16 18:15  优前程  阅读(2753)  评论(0)  编辑  收藏  举报