计算机网络总结_数据包序列号小于系统序列号-CSDN博客

本文链接：https://blog.csdn.net/weixin_45937795/article/details/123023660

1. HTTP总结

1.1. HTTP报文格式

HTTP请求由请求行、请求头部、空行和请求体四个部分组成。

请求行：包括请求方法，访问的资源URL，使用的HTTP版本。
请求头：格式为“属性名：属性值”，服务器会根据请求头来获取客户端的信息，主要有cookie，host，connection，accept-language，accept-encoding，user-agent。
请求体：用户的请求数据如用户名、密码等。

请求报文示例：

POST /xxx HTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=dabin 请求体

HTTP响应也由四个部分组成，分别是：状态行、响应头、空行和响应体。

响应行：协议版本，状态码以及状态描述。
响应头：响应头的字段主要有connection、content-type、content-encoding、content-length、set-cookie、Last-Modified、Cache-Control、Expires。
响应体：服务器返回给客户端的内容。

响应报文示例：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <body>响应体</body>
</html>

1.2. HTTP和HTTPS的区别，以及HTTPS有什么缺点？

区别：

1）HTTP协议是以明文的方式在网络中传输数据，而HTTPS协议传输的数据是经过SSL/TLS加密之后的，HTTPS具有更高的安全性。

2）HTTPS在TCP三次握手阶段之后，还需要进行SSL的handshake，协商加密使用的对称加密密钥。

SSL通信handshake过程

3）HTTPS协议需要服务端申请证书，浏览器安装对应的根证书。

4）HTTP协议端口是80，而HTTPS协议端口是443

HTTPS优点：

HTTPS传输数据过程中使用密钥进行加密，所以安全性更高

HTTPS协议可以认证用户和服务器，确保数据发送到正确的用户和服务器

HTTPS缺点：

HTTPS握手阶段延时较高：由于在进行HTTP会话之前还需要进行SSL握手，因此HTTPS协议握手阶段延时增加

HTTPS部署成本高：一方面HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书；另一方面由于采用HTTPS协议需要进行加解密的计算，占用CPU资源较多，需要的服务器配置或数目高

1.3. HTTP返回码

HTTP协议的相应报文由状态行，响应头部和响应包体组成，其响应状态码总体描述如下：

1xx：指示信息 – 表示请求已接收，继续处理。

2xx：成功 – 表示请求已被成功接收、理解、接受。

3xx：重定向 – 要完成请求必须进行更进一步的操作。

4xx：客户端错误 – 请求有语法错误或请求无法实现。

5xx：服务器端错误 – 服务器未能实现合法的请求。

常见状态码

1.4. HTTP长连接和短连接

参考资料

HTTP的长连接和短连接本质上是TCP长连接和短连接。在HTTP/1.0中默认使用短连接，在HTTP/1.1中默认使用长连接。

短连接的操作步骤：

建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接

长连接的操作步骤：

建立连接——数据传输…（保持连接）…数据传输——关闭连接

什么时候用长连接，短连接？

比如像数据库连接可以使用长连接，因为他需要频繁的进程增删改查，如果使用短连接频繁的通信将会降低效率，耗费资源。

像web网站的http服务一般使用短连接，因为长连接对于服务端来说会耗费一定的资源，如果客户端的并发量很大，那么每个用户都会占用一个连接，那么会耗费很多资源，并且降低服务器的性能。

1.5. HTTP1.0、HTTP1.1、HTTP2.0区别

参考资料

HTTP1.0与HTTP1.1的区别：

长连接： HTTP1.1默认长连接，HTTP1.0默认短连接（可以使用keep-alive参数变为长连接）
节约带宽： HTTP1.1支持只发送header信息（不带body），如果服务器返回100，则继续发送body，如果返回401，就可以不用发送了，节约了带宽。HTTP1.1支持传送内容的一部分。HTTP1.1支持文件断点续传功能。
host域： Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。

HTTP1.1与HTTP2.0的区别：

多路复用： 允许同时通过单一的 HTTP2.0连接发起多重的请求-响应消息。
二进制分帧： 在应用层和传输层之间增加一个二进制分帧层，提高传输性能。
首部压缩： HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
服务器推送： HTTP2.0允许服务器未经请求，主动向客户端发送资源。

1.6. GET和POST的区别

作用：get用于获取资源，post用于上传数据。
参数：get的参数在url中，post的参数存储在实体主体。
安全性：get是安全的，post不安全。因为get只是获取资源，不会改变服务器状态，而post上传的数据可能存在数据库中，会改变服务器状态。
幂等：get方法都是幂等的，post不是。幂等指多次请求和一次请求的结果是一致的。因为get并没有改变服务器的状态，所以每次请求都是一样的，而post可能更改了数据库中的内容，导致内容不一样。

1.7. Cookie和Session

由于HTTP 协议是无状态的，所以可以通过cookie或者session来保存用户身份。

相同之处：

cookie和session的共同之处都是用来跟踪浏览器用户身份的会话方式。

不同之处：

作用范围不同：Cookie保存在客户端，Session保存在服务器端。
有效期不同：Cookie可设置长时间保存，比如我们经常使用的默认登录功能，Session一般失效时间较短，客户端关闭或者Session超时都会失效。
隐私策略不同：Cookie存储在客户端，容易被窃取，Session存储在服务器端，安全性高一些。
存储大小不同：单个Cookie保存的数据不能超过4k，对于Session来说，没有上限，但是如果保存太多数据会影响服务器性能。

1.8. 什么是数字证书？

数字证书是指在互联网通讯中标志各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份。数字签名要解决的问题，是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖，就是靠数字签名技术。数字签名，是 CA 在给服务器颁发证书时，使用散列+加密的组合技术，在证书上盖个章，以此来提供验伪的功能。

1.9. 对称加密和非对称加密

参考资料

对称加密： 对称加密是加密和解密使用的密钥是一样的，相比于非对称加密，他的效率比较高，但是安全性比较低，发送信息过程中密钥可能会被破解。对称加密通常使用较小的密钥，一般为256bit，密钥越大，解密时间越长，但是密钥越小，越容易被黑客破解。
非对称加密： 非对称加密使用公钥和私钥，公钥发送给请求方，私钥留着自己解密，因为私钥只有自己持有，并不会发送出去，所以安全性更高。公钥和私钥的生成是采用一种复杂的数学函数，所以解密较复杂，效率较低。

非对称加密的使用过程：

1）A和B要进程信息通信，则A和B都产生自己的公钥和私钥

2）A将自己公钥发送给B，B将自己的公钥发送给A

3）A要给B发送消息时，在消息上通过B给A的公钥进行加密，然后发送给B

4）因为B有自己的私钥，所以就可以进行解密

5）B给A发送消息也是同理

SSL/TLS使用哪种方式进行加密？

SSL/TLS首先通过非对称加密将对称加密使用的密钥进行加密，发送给对方，然后信息通信时使用收到的对称加密的密钥进行通，这样就只进行了一次非对称加密，多次对称加密，保证效率的同时提高了安全性。

1.10. SSL/TLS协议建立详细流程

在这里插入图片描述

图来自：https://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

1）客户端向服务器发送请求，请求包括协议版本号，客户端生成的随机数(Client random)，以及客户端支持的加密方法

2）服务器端确认双方使用的加密方法，并给出数字证书以及服务器生成的随机数(Server random)

3）客户端判断证书是否有效，然后生成一个新的随机数(Premaster secret)并使用数字证书中的公钥，加密这个随机数，发送给服务器端

4）服务器端使用自己的私钥解密获取客户端发来的随机数

5）客户端和服务器端根据约定的加密方法，是用前面三个随机数，生成“对话密钥"(session key)，用来加密接下来的整个对话过程。

1.11.URL和URI的区别

URL为同一资源定位符 URI为同一资源标识符 URL可以看作URI的一个子集，URI通常包括URL和URN

简单举个例子来说，URI就像是一个人的身份证，可以通过身份证来标识一个人，URL就像是家庭住址一样，可以通过家庭住址来找到你，用来定位你。

2. TCP/UDP总结

2.1. TCP报文首部格式

参考资料

TCP报文段首部的前20个字节是固定的（下图），后面有4n字节是根据需要而增加的选项（n是整数）。因此TCP首部的最小长度是20字节。

在这里插入图片描述

源端口和目的端口：各占2个字节，分别写入源端口和目的端口
序号：Seq序号，占4个字节，32bit，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。（用来解决网络包乱序问题）
确认序号：Ack序号，占4个字节，32bit，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。（用来解决不丢包的问题。）
数据偏移：占4位，指TCP报文段的数据起始处距离TCP报文段的起始处多远。实际上就是指出TCP报文段首部长度。
保留：占6位，保留为今后使用。
标志位：
- URG：标志紧急指针是否有效
- ACK：标志确认号是否有效（确认报文段）。用于解决丢包问题。
- PSH：提示接收端立即从缓冲读走数据。
- RST：表示表示要求对方重新建立连接（复位报文段）
- SYN：表示请求建立一个连接。
- FIN：表示关闭连接。
窗口：占2个字节。接收窗⼝。⽤于告知对⽅（发送⽅）本⽅的缓冲还能接收多少字节数据。⽤于解决流控。
校验和：占两个字节。接收端⽤CRC检验整个报⽂段有⽆损坏。

2.2. 三次握手

三次握手过程：

在这里插入图片描述

一开始，客户端和服务端都处于CLOSED状态。先是服务器主动监听某个端口，处于LISTEN状态
客户端会随机初始化序号（client_isn），将此序号置于TCP首部的 [序号] 字段中，同时把SYN标志位置为1，表示SYN报文。接着把第一个SYN报文发送给服务端，表示向服务器发起连接，该报文不含应用层数据，之后客户端处于SYB-SENT状态。
服务器端收到客户端的SYN报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入TCP首部的 [序号] 字段中，其次把TCP首部的[确认应答号]字段填入client_isn + 1 ，接着把SYN和ACK置为 1 。最后该报文发给客户端，该报文也不包含应用层数据门之后服务端处于SYN-RECD状态。
客户端收到服务端报文之后，还要向服务端回应最后一个应答报文，首先该应答报文TCP首部ACK标志位置为 1 ，其次 [确认应答号] 字段填入 server_isn + 1 ，最后把该报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于ESTABLESHED状态。
服务器收到客户端的应答报文之后，也进入ESTABLESHED状态。

从上面的过程可以发现第三次握手是可以携带数据的，前两次握手时不可以携带数据的。

一旦完成三次握手，双方都处于 ESTABLESHED 状态，此时连接就建立完成，客户端和服务器就可以相互发送数据了。

为什么不能两次握手？ P135

阻止重复历史连接的初始化（主要原因）：可能会由于网络堵塞，导致第一次发送的连接没有到达接收端，超时重传后又发送一个连接给接收端，如果没有第三次握手，可能由于网络堵塞，两个请求连接都到达了，那么可能就会建立两个连接，造成了资源浪费（这也是为什么不能两次握手的原因）；如果两次连接都发送到了接收端，且接收端都进行了回应，那么客户端就会根据传来的ACK判断它是第一次发送的连接，还是第二次发送的连接，如果是第一次发送的连接，客户端会认定这是一个历史连接，且发送RST报文给接收端表示中止这一次连接，如果是第二次发送的链接，那么就会第三次握手建立连接。

为什么不能四次握手？

可以把第二次握手拆成两次，先发送一个确认报文段（ACK=1，ack=x+1），然后再发送一个同步报文段（SYN=1，seq=y），这样就变成了四次握手，但是这样的效果和三次握手是一样的，所以就没有必要多用一次，不仅耗时，而且消耗资源。

为什么第二次握手要传回SYN？

接收端也发送SYN是为了表明双方的通信通道都没有问题。

为什么第二次握手和第三次握手要传Ack？

确保信息的准确无误。

2.3. 四次挥手

在这里插入图片描述

客户端打算关闭连接，此时会发送⼀个 TCP ⾸部 FIN 标志位被置为 1 的报⽂，也即 FIN 报⽂，之后客

户端进⼊ FIN_WAIT_1 状态。

服务端收到该报⽂后，就向客户端发送 ACK 应答报⽂，接着服务端进⼊ CLOSED_WAIT 状态。

客户端收到服务端的 ACK 应答报⽂后，之后进⼊ FIN_WAIT_2 状态。

等待服务端处理完数据后，也向客户端发送 FIN 报⽂，之后服务端进⼊ LAST_ACK 状态。

客户端收到服务端的 FIN 报⽂后，回⼀个 ACK 应答报⽂，之后进⼊ TIME_WAIT 状态

服务器收到了 ACK 应答报⽂后，就进⼊了 CLOSED 状态，⾄此服务端已经完成连接的关闭。

客户端在经过 2MSL ⼀段时间后，⾃动进⼊ CLOSED 状态，⾄此客户端也完成连接的关闭。

每个⽅向都需要⼀个 FIN 和⼀个 ACK，因此通常被称为四次挥⼿。

为什么挥手需要四次？

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
服务器收到客户端的 FIN 报⽂时，先回⼀个 ACK 应答报⽂，⽽服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报⽂给客户端来表示同意现在关闭连接。

从上⾯过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN ⼀般都会分开发送，从⽽⽐三次握⼿导致多了⼀次。

为什么 TIME_WAIT等待的时间是2MSL？

MSL 是 Maximum Segment Lifetime，报⽂最⼤⽣存时间，它是任何报⽂在⽹络上存在的最⻓时间，超过这个时

间报⽂将被丢弃。因为 TCP 报⽂基于是 IP 协议的，⽽ IP 头中有⼀个 TTL 字段，是 IP 数据报可以经过的最⼤路

由数，每经过⼀个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报⽂通知源主机。

MSL 与 TTL 的区别： MSL 的单位是时间，⽽ TTL 是经过路由跳数。所以 MSL 应该要⼤于等于 TTL 消耗为 0 的

时间，以确保报⽂已被⾃然消亡。

TIME_WAIT 等待 2 倍的 MSL，⽐较合理的解释是：⽹络中可能存在来⾃发送⽅的数据包，当这些发送⽅的数据包

被接收⽅处理后⼜会向对⽅发送响应，所以⼀来⼀回需要等待 2 倍的时间。

⽐如如果被动关闭⽅没有收到断开连接的最后的 ACK 报⽂，就会触发超时᯿发 Fin 报⽂，另⼀⽅接收到 FIN 后，

会重发 ACK 给被动关闭⽅，⼀来⼀去正好 2 个 MSL。

2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK

没有传输到服务端，客户端⼜接收到了服务端᯿发的 FIN 报⽂，那么 2MSL 时间将重新计时。

在 Linux 系统⾥ 2MSL 默认是 60 秒，那么⼀个 MSL 也就是 30 秒。Linux 系统停留在 TIME_WAIT 的时

间为固定的 60 秒。

为什么需要 TIME_WAIT 状态？

防⽌具有相同「四元组」的「旧」数据包被收到；

保证「被动关闭连接」的⼀⽅能被正确的关闭，即保证最后的 ACK 能让被动关闭⽅接收，从⽽帮助其正常关闭；

TIME_WAIT 过多有什么危害？

第⼀是内存资源占⽤；

第⼆是对端⼝资源的占⽤，⼀个 TCP 连接⾄少消耗⼀个本地端⼝；

2.4. TCP怎么保证可靠性

TCP如何保证可靠性

校验和

TCP检验和的计算与UDP一样，在计算时要加上12byte的伪首部，检验范围包括TCP首部及数据部分，但是UDP的检验和字段为可选的，而TCP中是必须有的。TCP校验和计算方法： 发送方先将整个报文分为分为多个16位的段，然后将所有的段进行反码相加，将结果存在发送方TCP首部的校验和字段。接收方用相同的方法进行计算，求出校验和，然后将发送方与接收方的校验和进行相加，然后取反，如果结果为0，则就是正确的。

确认应答与序列号

序列号的作用： 保证可靠性；保证数据按序到达；提高效率，多次发送，一次确认；去除重复数据。

TCP通过确认应答机制实现可靠的数据传输。在TCP的首部中有一个标志位ACK，此标志位表示确认号是否有效。当发送方发送一个数据包，数据包的序列号seq=x，然后接收方返回一个确认后ack=y给发送方。

超时重传

当报文发出后一定时间内未收到接收方确认，发送方就会重传。（两种情况：一种是数据包在发送过去时丢包，另一种的接收方回应的响应包丢了）

重传时间的确定：

报文段发出到收到应答中间有一个报文段的往返时间RTT，显然超时重传时间RTO会略大于这个RTT，TCP会根据网络情况动态的计算RTT，即RTO是不断变化的。重传次数累计到一定次数后，TCP认为网络或对端主机出现异常，就会强行关闭连接。

连接管理（三次握手四次挥手）

连接管理机制即TCP建立连接时的三次握手和断开连接时的四次挥手。保证可靠的连接，是保证可靠性的前提。

流量控制

接收端处理数据的速度是有限的，如果发送方发送数据的速度过快，导致接收端的缓冲区满，而发送方继续发送，就会造成丢包，继而引起丢包重传等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制叫做流量控制。

在TCP报文段首部中有一个16位窗口长度，当接收端接收到发送方的数据后，在应答报文ACK中就将自身缓冲区的剩余大小，放入16窗口大小中。

注： 16位的窗口大小最大能表示65535个字节（64K），但是TCP的窗口大小最大并不是64K。在TCP首部中40个字节的选项中还包含了一个窗口扩大因子M，实际的窗口大小就是16位窗口字段的值左移M位。每移一位，扩大两倍。

拥塞控制

在这里插入图片描述

拥塞控制：防止过多的数据注入到网络中。几种拥塞控制的方法：慢开始、拥塞控制、快重传、快恢复。

慢开始

把拥塞窗口cwnd设置为一个最大报文段MSS的数值，而在每收到一个新报文段的确认之后，把拥塞窗口增加至多一个MSS的数值。每经过一个传输轮次（RTT），拥塞窗口就翻倍。为了阻止拥塞窗口增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。

当 cwnd < ssthresh 时，使用慢开始算法。

当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。

当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

拥塞避免

让拥塞窗口cwnd缓慢地增大，每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长。

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

快重传

有时个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口cwnd又设置为1，因而降低了传输效率。

快重传算法可以避免这个问题。快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认，使发送方及早知道有报文段没有到达对方。

发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待重传计时器到期。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

快恢复

当发送方连续收到三个重复确认，就会把慢开始门限ssthresh减半，接着把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。采用这样的拥塞控制方法使得TCP的性能有明显的改进。

2.5. 滑动窗口和流量控制

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

2.6. TCP/IP数据链路层的交互过程

网络层等到数据链层用mac地址作为通信目标，数据包到达网络等准备往数据链层发送的时候，首先会去自己的arp缓存表(存着ip-mac对应关系)去查找改目标ip的mac地址，如果查到了，就讲目标ip的mac地址封装到链路层数据包的包头。如果缓存中没有找到，会发起一个广播：who is ip XXX tell ip XXX,所有收到的广播的机器看这个ip是不是自己的，如果是自己的，则以单拨的形式将自己的mac地址回复给请求的机器

2.7. TCP和UDP的区别和各自适用的场景

TCP和UDP区别

1）连接

TCP是面向连接的传输层协议，即传输数据之前必须先建立好连接。

UDP无连接。

2）服务对象

TCP是点对点的两点间服务，即一条TCP连接只能有两个端点；

UDP支持一对一，一对多，多对一，多对多的交互通信。

3）可靠性

TCP是可靠交付：无差错，不丢失，不重复，按序到达。

UDP是尽最大努力交付，不保证可靠交付。

4）拥塞控制，流量控制

TCP有拥塞控制和流量控制保证数据传输的安全性。

UDP没有拥塞控制，网络拥塞不会影响源主机的发送效率。

5）报文长度

TCP是动态报文长度，即TCP报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的。

UDP面向报文，不合并，不拆分，保留上面传下来报文的边界。

6）首部开销

TCP首部开销大，首部20个字节。

UDP首部开销小，8字节。（源端口，目的端口，数据长度，校验和）

TCP和UDP适用场景

从特点上我们已经知道，TCP 是可靠的但传输速度慢，UDP 是不可靠的但传输速度快。因此在选用具体协议通信时，应该根据通信数据的要求而决定。

若通信数据完整性需让位与通信实时性，则应该选用TCP 协议（如文件传输、重要状态的更新等）；反之，则使用 UDP 协议（如视频传输、实时通信等）。

2.8. TCP粘包

什么是TCP粘包问题？

TCP粘包就是指发送方发送的若干包数据到达接收方之后粘成了一个包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能来自发送方，也可能来自接收方。

造成TCP粘包的原因？

（1）发送方：TCP默认使用Nagle算法（减少网络中报文的数量）

Nagle算法主要做的事情：

只有上一个分组得到确认，才会发送下一个分组
收集多个小分组，在一个确认到来时一起发送

所以当两个小分组一起发送时，就会导致粘包问题。

（2）接收方：TCP收到数据包时，应用层不会马上处理，而是存在缓冲区中，当应用层读取缓冲区中的数据包时，就可能读取到多个首尾粘在一起的包。

如何处理粘包问题？

发送方关闭Nagle算法。
格式化数据（每条数据都设置开始符和结束符）或者发送长度（发送方发送数据的时候通过发送数据长度），这样接收方的应用层就可以一条一条的读取。

为什么UDP不会粘包？

TCP是基于流的传输，即将大的数据拆成几份发送，所以会产生粘包，而UDP面向消息传输，接收方一次只接受一条独立的信息，所以不存在粘包。

2.9. 怎么实现可靠UDP

参考资料

想要实现可靠的UDP可以在应用层（传输层无法保证数据的可靠传输）参照可靠TCP的一些传输方式，例如添加seq/ack机制，添加发送和接受缓冲区，添加超时重传的机制。

详细说明：送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。

目前有一些开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

2.10. UDP丢包原因和如何优化

1）UDP包过大： 增加系统发送或接收缓冲区的大小

2）发送速率过快： 增加应答机制，处理完一个包后，再继续发包

recvfrom()接收到数据之后处理速度太慢

服务器程序启动之出，开辟两个线程，一个线程专门用于接收数据包，并存放在应用层的缓存区；另外一个线程用于专门处理和响应数据包请求，避免因为处理数据造成数据丢包。其本质上还是增大了缓冲区大小，只是将系统缓冲区转移到了自己的缓冲区。

最复杂的方式

在应用层实现丢包重发机制和超时机制，确保数据包不丢失。

来源：https://blog.csdn.net/c_base_jin/article/details/103229620

2.11 IP报文首部

2.12 TCP和UDP相关的协议和端口号

2.13 TCP字节流

TCP协议是面向字节流的，那么TCP是怎么决定一次发送多少数据呢？可以通过发送窗口、拥塞窗口、路径上的最大传输单元（MTU）、输出队列数据总量等来判断。

2.14 拥塞控制和流量控制的区别

拥塞控制： 是防止过多的数据注入到网络中，导致网络拥塞。

流量控制： 是防止发送方一下子发送过多的数据到接收方，导致接收方的缓存放不下。

两种方法都是对发送方的行为进行控制。

3. 其他

3.1. 在浏览器地址栏键入URL，按下回车之后会经历以下流程

1）浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址；

2）解析出 IP 地址后，根据该 IP 地址和默认端口80，和服务器建立TCP连接；

3）浏览器发出读取文件（URL中域名后面部分对应的文件）的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器；

4）服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器；

5）释放 TCP连接；

6）浏览器将该 html 文本并显示内容

在这个过程中，用到了哪些协议？

dns协议，将域名解析为对应的ip地址
tcp协议，连接服务器
ip协议，tcp连接发送的数据在网络层中使用ip协议
ospf协议(open shortest path fast，开放式最短路径优先)，路由器之间的选择使用ospf协议
arp协议，路由器与服务器通信，需要通过arp协议将ip地址转换为mac地址
http协议，在tcp连接后，采用http协议访问网页

3.2. ping一个域名的过程

参考资料

ping （Packet Internet Groper）是一种因特网包探索器，用于测试网络连接量的程序。Ping是工作在 TCP/IP网络体系结构中应用层的一个服务命令，主要是向特定的目的主机发送 ICMP（Internet Control Message Protocol 因特网报文控制协议）Echo 请求报文，测试目的站是否可达及了解其有关状态。

过程：

第一步，对域名进行DNS解析，得到该域名所对应的ip地址，第二步，对该ip进行ARP解析，得到MAC地址，第三步，向域名主机发送ICMP报文，等到主机收到来到域名主机的回应报文之后，就说明该主机到域名主机是连通可达的。

3.3. 端口

端口分为三类，分别是周知端口、动态端口、注册端口

周知端口：范围从0到1023，即广为人知的端口号，比如http是80，https是443
动态端口：范围从49152到65535，它一般不固定分配某种服务，而是动态分配
注册端口：端口1024到49151，分配给用户进程或应用程序。这些主要是用户选择安装的一些应用程序

作用：端口是tcp/ip协议中传输层的概念，用于区分同一台主机中的不同应用

3.4. DNS解析的过程

1）客户端提出域名解析请求，并将该请求发送给本地的域名服务器

2）本地的域名服务器先查询本地的缓存，如果有该记录项，则将查询结果返回给客户端

3）如果本地的域名服务器没有缓存，则本地的域名服务器向根域服务器发送请求，然后根域服务器返回给本地域名服务器一个所查域（跟的子域）的主域名服务器、

4）本地服务器再向上一步返回的域名服务器发送请求，然后接受请求的服务器查询自己的缓存，如果没有该纪录，则返回相关的下级的域名服务器的地址。

5）重复第4步，直到找到正确的纪录。

6）本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时还将结果返回给客户机。

在这里插入图片描述

3.5. ARP协议

根据ip和子网掩码计算两个ip是不是属于同一个网段

不同网段之间的通信

同一网段内：

首先源主机查找自己的ARP列表是否有目的IP的MAC地址，如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。网络中的所有主机收到这个ARP请求后，查看数据包中的目的IP是否和自己的IP一致，如果不同，就忽略此包，如果相同，先将发送端的IP和MAC地址添加到自己的ARP列表，然后以单播的形式发送一个ARP响应包给源主机。

不同网段内：

首先源主机查找自己的ARP列表是否有目的IP的MAC地址，然后通过上面同一网段的方式得到网关的MAC地址，然后将目的IP与网关的MAC地址写入ARP列表，然后源主机就将数据包发送到自己的网关，源主机网关从数据包首部提取IP发现不是给自己的，于是查找路由表找到目的IP对应的网关，然后通过路由转发发送到目的主机网关，目的主机网关继续通过上诉方法得到目的主机的MAC地址，然后将源主机网关发送过来的数据包重新封装，然后发送给目的主机。

注：
a.源IP和目标IP始终不变。
b.ARP请求以广播发送，单播回应。
c.路由器隔离广播，每一个网段都是独立的广播域。
d.跨网段通信需要网关的mac地址。

3.6. 计算机网络体系结构

OSI体系结构（应用层、表示层、会话层、运输层、网络层、数据链路层、物理层）概念清楚，理论完整，它是先有模型，后有协议，先有标准，后进行实践，它既复杂又不实用。在OSI的理论概念下有了TCP/IP体系结构（应用层、运输层、网络层、数据链路层），它是先有了协议和应用，然后再提出了模型，且是参照了OSI模型。

OSI是一种理论下的模型，而TCP/IP已经被广泛应用，称为网络互联实施上的标准。

TCP/IP体系结构：

应用层： 应用层就只专注与为用户提供提供应用功能，不用去关心数据时如何传输的。因此，当两个不同设备的应用需要通信的时候，应用层就把数据传给运输层，把应用层交互的数据称为报文。应用层常用的协议：DNS协议、HTTP协议、电子邮件SMIP协议。

运输层： 运输层的任务就是负责向两台不同设备之间进程的通信提供通用的数据传输服务，运输层将应用层传来的数据加上TCP首部之后，就形成了TCP报文，如果数据包很大，可以将数据进行分块。运输层常用的协议：TCP、UDP。

网络层： 网络层最常使用的是IP协议，IP协议会将运输层传下来的报文作为数据部分，再加上IP包头组装成IP报文。然后选择合适的路由进行数据的传送。

链路层： 网络层要将IP报文发送给指定的设备，但是他只知道另一台设备的IP地址，并不知道这个IP是属于哪个设备，这个时候就需要链路层通过IP地址找到目的的的MAC地址，这样就能找到指定设备了。

OSI和TCP/IP对比

参考资料

在这里插入图片描述

3.7. IP地址作用，以及MAC地址作用

IP地址作用：

IP地址是IP协议提供的一种统一的地址格式，为互联网上的每一个网络的每一台主机分配的一个逻辑地址，以此来屏蔽物理地址的差异。

MAC地址的作用：

MAC地址是一个硬件地址，用来定义网络设备的位置，主要由数据链路层负责。

IP地址和MAC地址的差别：

两者地址使用不同。
IP地址是指Internet协议使用的地址，而MAC地址是Ethernet协议使用的地址。当存在一个附加层的地址寻址时，设备更易于移动和维修。
分配依据不同。IP地址的分配是基于网络拓朴，MAC地址的分配是基于制造商。
IP地址是可以自动分配的，MAC地址在每个网卡出场的时候就有一个全球唯一的MAC地址，所以很多的验证软件就是验证mac地址的。
地址能否更改不同。
IP是可以更改的，mac地址虽然也可以更改，但是一般用不上，除非要用来绕过一些验证软件的。网卡在通讯的时候通过mac地址相互识别。
长度不同。
IP地址为32位，MAC地址为48位。
寻址协议层不同。
IP地址应用于OSI第三层，即网络层，而MAC地址应用在OSI第二层，即数据链路层。

3.8. QUIC

QUIC是谷歌推出的基于UDP的传输协议，它实现了TCP+HTTPS和HTTP2.0的功能，目的是保证可靠性的同时降低网络延迟。因为UDP是一个简单传输协议，基于UDP可以摆脱TCP传输确认、重传慢启动等因素，建立安全连接只需要一个往返时间，他还实现了HTTP2.0多路复用，头部压缩等功能。

3.9. 基于TCP、UDP的协议有哪些

https://www.likecs.com/show-204665818.html

基于TCP（基于TCP协议的都用C/S模式）：

HTTP：超文本传输协议，80端口
FTP：文件传输协议，20端口用于传输数据，21端口用于传输控制信息
SMTP：简单邮件传输协议，25端口
TELNET：远程登录，23端口
SSH：22端口

基于UDP：

DNS：域名服务，53端口
TFTP：简单文件传输协议，69端口
SNMPS：简单网络管理协议，通过UDP端口161接收，只有Trap信息采用UDP端口162。
NTP：网络时间协议，123端口

3.10. tracert

tracert是路由跟踪程序，用于确定数据包到达目标所经过的路径。探测数据包从源地址到目的地址经过的路由器IP地址。tracert使用的是ICMP协议。

实现原理：

1、tracert发出TTL值为1的ICMP数据包（40个字节、源地址、目标地址和发出时间标签，一般发3个）

2、当到达路径上第一个路由器时，路由器会将，TTL值减1

3、此时TTL值为0，该路由器将此数据包丢弃，向源地址返回一个ICMP超时通知（数据包的源地址、路由器的IP地址）

4、当tracert收到该数据包，获得了这个路径上的第一个路由器的地址

5、tracert再发送另一个TTL为2的数据包

6、第一个路由器会将此数据包转发给第二个路由器

7、当TTL=0，第二个路由器返回一个超时通知，tracert得到第二个路由器地址

8、Tracert每次发出数据报时便会将TTL加1，发现下一个路由器，这个动作一直重复，直到到达目的地或者确定目标主机不可到达为止，到达目的IP后，目标主机并不返回超时报文

3.11 IP子网的划分

https://blog.csdn.net/m0_37482190/article/details/94388353

互联网是怎么通过ip地址访问的？

通过路由器，路由设备当中有一张路由表，该路由表记录了所有ip地址的位置，这样就可以进行包的转发了，如果我们不区分网络地址，那么这张路由表当中就要保存有所有IP地址的方向，这张路由表就会很大，所以我们的ip地址由网络号和主机号组成。

IP地址的分类：

IP地址空间划分为A，B，C，D，E五类，其中A，B，C是基本了，D、E类作为多播和保留使用.

类别	最大网络数	IP地址范围	单个网段最大主机数	私有IP地址范围
A	126（2^7-2）	0.0.0.0 ~ 127.255.255.255	16777214	10.0.0.0 ~ 10.255.255.255
B	16384（2^14）	128.0.0.0 ~ 191.255.255.255	65534	172.16.0.0 ~ 172.31.255.255
C	2097152（2^21）	192.0.0.0 ~ 223.255.255.255	254	192.168.0.0 ~ 192.168.255.255