秋招备战——计算机网络-CFANZ编程社区

TCP/IP协议

指能够在多个不同网络间实现信息传递的协议簇，包含多个协议。

OSI七层协议：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VKuNoi2y-1662292662605)(en-resource://database/1099:1)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uiY3CHzI-1662292662607)(en-resource://database/1101:1)]

ARP协议

广播的方式发送数据包，获取目标主机的mac地址。有了IP地址我们可以判断在一个子网中，在一个子网络我们在链路层也讲过是通过MAC地址进行通信的，我们现在只知道目标的IP地址，如何才能拿到目标主机的MAC地址呢，这个时候引出了ARP协议。

发送端主机通过广播的方式把自己的数据包发出去，所有主机接收后拆开包，发现目标ip为自己的，就响应，返回自己的mac。数据包格式如下：
数据包格式：（发送端的MAC地址，目标MAC地址，发送端IP地址,目标IP地址,数据）

ICMP协议

一个新搭建好的网络，往往需要先进行一个简单的测试，来验证网络是否通畅，但是IP协议并不是可靠传输，如果包丢了，IP协议并不能通知传输层是否丢包以及丢包的原因。 于是有了ICMP协议。

ICMP协议的主要功能：

1、确认IP数据包是否成功达到目标地址；
2、通知在发送过程中IP包被丢失的原因。

需要注意的是：

（1）ICMP是基于IP协议工作的，但是它并不是传输层的功能，因此仍然把它归结为网络层协议；

（2）ICMP只能搭配IPv4使用，如果是IPv6的情况下，需要使用ICMPv6。我们平常所用的ping命令其实就用到了ICMP。

那么如何验证呢？

（1）ping命令会先发送一个ICMP Echo Request给对端

（2）对端接收后，会返回一个ICMP Echo Reply

（3）若没有返回，就是超时了，会认为指定的网络地址不存在

网络层是建立主机到主机的通信，传输层的功能就是建立端口到端口的通信

流量控制和拥塞控制

（1）流量控制

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

（2）拥塞控制

在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。拥塞控制是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。前提是网络能够承受现有的网络负荷。为了进行拥塞控制，TCP发送方要维持一个拥塞窗口和状态量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接收窗口中最小的一个。拥塞控制的四种算法：慢开始、拥塞避免、快重传（FRR）和快恢复。

流量控制和拥塞控制的差别：

拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是一个端到端的问题。流量控制所要做到的是抑制发送端发送的速率，以便使接收端来得及接收。

HTTP协议

超文本传输协议，web是建立在HTTP协议上通信的。HTTP的准确翻译是超文本转移协议。1990年问世，1996年正式作为标准HTTP1.0。

其存在缺点：第一点是无法复用。Http1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户端也不记录过去的请求。如果还要请求其他资源需要建立新的连接。

第二点是队头阻塞，holb是指一系列包因为第一个包被阻塞；当页面中需要请求很多资源的时候，HOLB会导致在达到最大请求数量时，剩余的资源需要等待其它资源请求完成后才能发起请求。这会导致带宽无法被充分利用，以及后续健康请求被阻塞。

因此到了1997年，HTTP1.1版本，也是目前主流的版本，FRC2616版本。

优化：①加入缓存机制；②宽带优化以及网络连接的使用；③错误通知的管理；④长连接

局限性：①不能多路复用；②浏览器限制了同一个域名下的请求数量；③有时传输成本大：header里携带的内容过大，在一定程度上增加了传输的成本。

**谷歌于2009年公开了SPDY协议，W3C将SPDY协议引入到HTTP协议中，在2012年发布HTTP2.0协议。**优化的优点：①二进制格式传输数据：相比之前的文本格式，二进制格式的数据解析起来效率更高；②双工模式：不仅客户端可以同时发送多个请求，服务端也能同时处理多个请求，解决了队头堵塞的问题。使用了多路复用技术，做到可以同时连接并发处理多个请求。③提高利用率：将请求和响应信息字段建立一张表，为表中每个字段建立索引，客户端和服务端共同使用这个表，他们之间的索引号来表示信息字段，并以压缩方式存储，提高了利用率；④服务器推送：不经请求服务器主动向客户端发送数据。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ycuMws9I-1662292662608)(en-resource://database/1103:1)]

QUIC，快速UDP互联网连接（HTTP3.0）已经应用在了chrome浏览器

TCP协议虽然可以保证不丢包，但还是存在一些局限性。谷歌为了提高联网的速度，吸收TCP快速打开的技术，缓存当前上下文等优点，基于UDP协议开发出了QUIC。

优化：①队头阻塞问题完全解决：不同的流之间相互独立，互不干扰。②切换网络时连接保持：移动端在切换网络时，如切换WiFi或者时４G或者５G网络时，依然可以保持连接服务。

常用的状态码

200，请求正常处理；301，重定向；401未授权；403访问拒绝；404未找到资源；500服务器内部错误。4开头的状态码，后端接口接正确时，一般时前端出问题；5开头的状态码，一般都是后端的问题。

TCP传输可靠性怎么保证

1、字节编号机制，为了更好的发送和接收；2、数据段的确认机制，确认应答机制；3、TCP超时重传机制，保证传输可靠性的一种重要保证。

TCP握手为什么不能是2次

主要是为了防止已经失效的连接请求报文突然又传到了服务器，从而导致不必要的错误和资源的浪费
两次握手只能保证单项连接是畅通的。因为TCP是一个双向传输协议，只有经过第三次握手，才能确保双向都可以接收到对方发送的数据。

三次握手和四次挥手

三次握手

第一次握手：客户端给服务器发送一个 SYN 报文。
第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。
第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。
服务器收到ACK报文后，三次握手建立完成

SYN：建立连接时的同步序列号
seq：标记数据段的顺序
ACK：确认号

三次握手才能确认双方的接受与发送能力是否正常。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
四次挥手

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
第二次握手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时，如果过了这个计时没有再次收到 FIN 报文，则代表对方成功就是 ACK 报文，此时处于 CLOSED 状态。