第一部分：协议层次以及它们的服务类型
第二部分：应用层
1.HTTP 头部包含哪些信息.
通用头部，请求头部，响应头部和实体头部。
2.Keep-Alive 和非 Keep-Alive 区别，对服务器性能有影响吗
非Keep-alive：早期HTTP1.0，浏览器发起http请求需要与服务器建立新的TCP连接，请求处理后连接立即断开，重新请求重新连接。但每一个这样的连接，客户机和服务器都要分配 TCP 的缓冲区和变量，这给服务器带来的严重的负担。
Keep-alive：HTTP1.1默认持久连接，同一客户机可以连续请求通过相同的连接进行传送，一台服务器多个web页面也可通过单个TCP连接传送给同一个客户机。但长时间保持TCP连接会导致系统资源被无效占用。
3.HTTP 长连接短连接使用场景是什么
长连接：多用于操作频繁，点对点的通讯，而且客户端连接数目较少的情况。例如即时通讯、网络游戏等。
短连接：用户数目较多的Web网站的 HTTP 服务一般用短连接。例如京东，淘宝这样的大型网站一般客户端数量达到千万级甚至上亿，若采用长连接势必会使得服务端大量的资源被无效占用，所以一般使用的是短连接。
4.怎么知道 HTTP 的报文长度
响应报文是发给客户端看的啊，服务器肯定知道有多少字节，但是在响应报文中有两种表现形式。
对于小点的文件，直接给出 content-length,也就是本次返回的数据长度
对于大文件，使用 Transfer-Encoding:chunked 字段，不传输数据长度，客户端只知道是分组传输，这也是订好了协议，客户端收到了会进行组装。
5.HTTP 方法了解哪些
http1.0：
get（读取数据）、head（获取报头）、post（提交数据处理请求）；
http1.1：（增加）
put（增或换）、delete（删除）、options（返回支持方法）、connect（server代理访问）、trace（服务器返回接收数据）、patch（局部更新）
POST 方法 发送数据给服务器. 请求主体的类型由 Content-Type 首部指定.
PUT 和POST方法的区别是,PUT方法是幂等的：连续调用一次或者多次的效果相同（无副作用）。连续调用同一个POST可能会带来额外的影响，比如多次提交订单。
6.GET和POST的区别
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务端响应200，请求成功。
对于POST方式的请求，浏览器会先发送http header给服务端，告诉服务端等一下会有数据过来，服务端响应100 continue，告诉浏览器我已经准备接收数据，浏览器再post发送一个data给服务端，服务端响应200，请求成功。
7.GET 的长度限制是多少
GET 和 POST
get 将参数直接写入 url 中进行访问
字符串类型，ASCII编码除去 { 和}
最大长度，取决于浏览器
IE 2KB+35
FireFox 64KB
Chrome 8KB-10
设计的目的是向服务器检索、获取资源信息
参数部分以 ? 开始由 & 分隔键值对，每个 = 左边为键，右边为值
post 通过提交表单访问
可以传入多种数据类型
理论上讲，post 方法是没有大小限制的，而真正起限制作用的是服务器处理程序的处理能力。
最初的设计也是为了填表，也就是提交、修改、上传信息
8.HTTP 与 HTTPs 的工作方式（建立连接的过程）
HTTP:默认用TCP协议的80端口
HTTPS:
1.客户端请求服务器443端口，简历TCP连接
2.客户端发送支持的对称加密算法列表和密钥长度
3.服务器根据双方共同支持的加密算法列表选择一种返回给客户端
4.服务器返回自身的CA证书，证书包括了服务器域名和公钥
5.客户端用本地证书库的根证书校验CA证书，生成随机密码串作为后续对称加密的种子，用公钥加密发送给服务器
6.服务器用私钥解密报文，得到随机密码串，用协商好的对称加密算法和种子，加密数据报文发送给客户端
7.SSL连接建立
9.HTTPS 和 HTTP 的区别
加密、端口、CA、响应速度；
10.HTTPS 的加密方式
HTTPS 采用对称加密和非对称加密相结合的方式
11. 客户端为什么信任第三方证书
12.HTTP 是不保存状态的协议,如何保存用户状态
基于Session，服务器创建并保存键值对：SessionId-Session，然后将SessionId下发给客户端，客户端将其存在Cookie中，每次请求带上这个SessionId，服务器就可以将状态和会话联系起来。
基于Cookie，服务器发送响应消息时在响应头中设置Set-Cookie字段，存储客户端的状态信息。客户端根据这个字段来创建Cookie并在请求时带上（每个Cookie都包含着客户端的状态信息），从而实现状态保持。
二者的区别：后者完全将会话状态存储在浏览器Cookie中。
Cookie被禁用了，可以通过重写URL的方式将会话标识放在URL的参数里
13. 状态码
200 请求成功
204 请求成功但无内容返回
206 范围请求成功
301 永久重定向； 30(2|3|7)临时重定向，语义和实现有略微区别；
304 带if-modified-since 请求首部的条件请求，条件没有满足
400 语法错误（前端挨打）
401 需要认证信息
403 拒绝访问
404 找不到资源
412 除if-modified-since 以外的条件请求，条件未满足
500 服务器错误（后端挨打）
503 服务器宕机了（DevOps or IT 挨打）
14.HTTP/1.1 和 HTTP/1.0 的区别
主要区别如下：
缓存处理：在 HTTP/1.0 中主要使用 header 里的 if-modified-Since, Expries 来做缓存判断的标准。而 HTTP/1.1 请求头中添加了更多与缓存相关的字段，从而支持更为灵活的缓存策略，例如 Entity-tag, If-Unmodified-Since, If-Match, If-None-Match 等可供选择的缓存头来控制缓存策略。
节约带宽： 当客户端请求某个资源时，HTTP/1.0 默认将该资源相关的整个对象传送给请求方，但很多时候可能客户端并不需要对象的所有信息。而在 HTTP/1.1 的请求头中引入了 range 头域，它允许只请求部分资源，其使得开发者可以多线程请求某一资源，从而充分的利用带宽资源，实现高效并发。
错误通知的管理：HTTP/1.1 在 1.0 的基础上新增了 24 个错误状态响应码，例如 414 表示客户端请求中所包含的 URL 地址太长，以至于服务器无法处理；410 表示所请求的资源已经被永久删除。
Host 请求头：早期 HTTP/1.0 中认为每台服务器都绑定一个唯一的 IP 地址并提供单一的服务，请求消息中的 URL 并没有传递主机名。而随着虚拟主机的出现，一台物理服务器上可以存在多个虚拟主机，并且它们共享同一个 IP 地址。为了支持虚拟主机，HTTP/1.1 中添加了 host 请求头，请求消息和响应消息中应声明这个字段，若请求消息中缺少该字段时服务端会响应一个 404 错误状态码。
长连接：HTTP/1.0 默认浏览器和服务器之间保持短暂连接，浏览器的每次请求都需要与服务器建立一个 TCP 连接，服务器完成后立即断开 TCP 连接。HTTP/1.1 默认使用的是持久连接，其支持在同一个 TCP 请求中传送多个 HTTP 请求和响应。此之前的 HTTP 版本的默认连接都是使用非持久连接，如果想要在旧版本的 HTTP 协议上维持持久连接，则需要指定 Connection 的首部字段的值为 Keep-Alive。
15.HTTP/1.X 和 HTTP/2.0 的区别
二进制传送：之前版本 数据都是用文本传输，因为文本有多种格式，所以不能很好地适应所有场景； 2.0传送的是二进制，相当于统一了格式
多路复用：1.1虽然默认复用TCP连接，但是每个请求是串行执行的，如果前面的请求超时，后面的请求只能等着（也就是线头阻塞）； 2.0的时候每个请求有自己的ID，多个请求可以在同一个TCP连接上并行执行，不会互相影响
header压缩：每次进行HTTP请求响应的时候，头部里很多的字段都是重复的，在2.0中，将字段记录到一张表中，头部只需要存放字段对应的编号就行，用的时候只需要拿着编号去表里查找就行，减少了传输的数据量
服务端推送：服务器会在客户端没发起请求的时候主动推送一些需要的资源，比如客户端请求一个html文件，服务器发送完之后会把和这个html页面相关的静态文件也发送给客户端，当客户端准备向服务器请求静态文件的时候，就可以直接从缓存中获取，就不需要再发起请求了
16. DNS 的作用和原理
17. DNS为什么用UDP
DNS 既使用 TCP 又使用 UDP。
当进行区域传送（主域名服务器向辅助域名服务器传送变化的那部分数据）时会使用 TCP，因为数据同步传送的数据量比一个请求和应答的数据量要多，而 TCP 允许的报文长度更长，因此为了保证数据的正确性，会使用基于可靠连接的 TCP。
当客户端向 DNS 服务器查询域名 ( 域名解析) 的时候，一般返回的内容不会超过 UDP 报文的最大长度，即 512 字节。用 UDP 传输时，不需要经过 TCP 三次握手的过程，从而大大提高了响应速度，但这要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。
18. 如何实现DNS劫持
具体实施步骤如下：
① 获取要劫持的域名信息：攻击者首先会访问域名查询站点查询要劫持的域名信息。
② 控制域名相应的 E-MAIL 账号：在获取到域名信息后，攻击者通过暴力破解或者专门的方法破解公司注册域名时使用的 E-mail 账号所对应的密码。更高级的攻击者甚至能够直接对 E-mail 进行信息窃取。
③ 修改注册信息：当攻击者破解了 E-MAIL 后，会利用相关的更改功能修改该域名的注册信息，包括域名拥有者信息，DNS 服务器信息等。
④ 使用 E-MAIL 收发确认函：在修改完注册信息后，攻击者在 E-mail 真正拥有者之前收到修改域名注册信息的相关确认信息，并回复确认修改文件，待网络公司恢复已成功修改信件后，攻击者便成功完成 DNS 劫持。
预防手段还是很明显的：直接使用IP访问或者直接指定DNS服务器
19.socket（）套接字有哪些
套接字主要有以下三种类型：
流套接字（SOCK_STREAM）：流套接字基于 TCP 传输协议，主要用于提供面向连接、可靠的数据传输服务。由于 TCP 协议的特点，使用流套接字进行通信时能够保证数据无差错、无重复传送，并按顺序接收，通信双方不需要在程序中进行相应的处理。
数据报套接字（SOCK_DGRAM）：和流套接字不同，数据报套接字基于 UDP 传输协议，对应于无连接的 UDP 服务应用。该服务并不能保证数据传输的可靠性，也无法保证对端能够顺序接收到数据。此外，通信两端不需建立长时间的连接关系，当 UDP 客户端发送一个数据给服务器后，其可以通过同一个套接字给另一个服务器发送数据。当用 UDP 套接字时，丢包等问题需要在程序中进行处理。
原始套接字（SOCK_RAW）：由于流套接字和数据报套接字只能读取 TCP 和 UDP 协议的数据，当需要传送非传输层数据包（例如 Ping 命令时用的 ICMP 协议数据包）或者遇到操作系统无法处理的数据包时，此时就需要建立原始套接字来发送。）
20. URI（统一资源标识符）和 URL（统一资源定位符）之间的区别
21. 为什么 fidder，charles 能抓到你的包【抓取数据包的过程
如果你访问一个网站很慢，怎么排查和解决
其他协议
对于应用层来说，考察的重点集中在 HTTP 协议和 DNS 这两块，其他协议考察较少，我们仅加以了解即可。
FTP（File Transfer Protocol，文件传输协议）是用于在网络上进行文件传输的一套标准协议，使用客户/服务器模式，使用 TCP 数据报，提供交互式访问，双向传输。
TFTP（Trivial File Transfer Protocol，简单文件传输协议）一个小且易实现的文件传输协议，也使用客户/服务器方式，使用 UDP 数据报，只支持文件传输而不支持交互，没有列目录，不能对用户进行身份鉴定。
SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）是在 Internet 传输 Email 的标准，是一个相对简单的基于文本的协议。在其之上指定了一条消息的一个或多个接收者（在大多数情况下被确认是存在的），然后消息文本会被传输。可以很简单地通过 Telnet 程序来测试一个 SMTP 服务器。SMTP 使用 TCP 端口 25。
DHCP
DHCP ( Dynamic Host Configuration Protocol，动态主机设置协议 ) 是一个局域网的网络协议，使用 UDP 协议工作，主要有两个用途：
用于内部网络或网络服务供应商自动分配 IP 地址给用户
用于内部网络管理员作为对所有电脑作中央管理的手段
SNMP
SNMP（Simple Network Management Protocol，简单网络管理协议）构成了互联网工程工作小组（IETF，Internet Engineering Task Force）定义的 Internet 协议族的一部分。该协议能够支持网络管理系统，用以监测连接到网络上的设备是否有任何引起管理上关注的情况。
网页解析全过程【用户输入网址到显示对应页面的全过程】
① DNS 解析：当用户输入一个网址并按下回车键的时候，浏览器获得一个域名，而在实际通信过程中，我们需要的是一个 IP 地址，因此我们需要先把域名转换成相应 IP 地址。【具体细节参看问题 16，17】
② TCP 连接：浏览器通过 DNS 获取到 Web 服务器真正的 IP 地址后，便向 Web 服务器发起 TCP 连接请求，通过 TCP 三次握手建立好连接后，浏览器便可以将 HTTP 请求数据发送给服务器了。【三次握手放在传输层详细讲解】
③ 发送 HTTP 请求：浏览器向 Web 服务器发起一个 HTTP 请求，HTTP 协议是建立在 TCP 协议之上的应用层协议，其本质是在建立起的TCP连接中，按照HTTP协议标准发送一个索要网页的请求。在这一过程中，会涉及到负载均衡等操作。
拓展：什么是负载均衡？
负载均衡，英文名为 Load Balance，其含义是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如 FTP 服务器、Web 服务器、企业核心服务器和其他主要任务服务器等，从而协同完成工作任务。负载均衡建立在现有的网络之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、增加吞吐量、加强网络处理能力并提高网络的灵活性和可用性。
负载均衡是分布式系统架构设计中必须考虑的因素之一，例如天猫、京东等大型用户网站中为了处理海量用户发起的请求，其往往采用分布式服务器，并通过引入反向代理等方式将用户请求均匀分发到每个服务器上，而这一过程所实现的就是负载均衡。
④ 处理请求并返回：服务器获取到客户端的 HTTP 请求后，会根据 HTTP 请求中的内容来决定如何获取相应的文件，并将文件发送给浏览器。
⑤ 浏览器渲染：浏览器根据响应开始显示页面，首先解析 HTML 文件构建 DOM 树，然后解析 CSS 文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。
⑥ 断开连接：客户端和服务器通过四次挥手终止 TCP 连接。【其中的细节放在传输层详细讲解】
第三部分：传输层
1.三次握手和四次挥手机制
2.三次握手的时候每次握手信息对方没有收到会怎么样
简单来说就是 重传 上一次的包 或者 这一次的包，因为这一次的不成功可能是由这一次的包未成功发送或者上一次的包未成功接收导致的
重传有重传次数限制，可配置，超过重传次数代表建立连接失败
第一次握手SYN丢失：客户端重传SYN（每次超时重传的RTO是翻倍上涨的）
第二次握手ACK、SYN丢失：客户端重传SYN + 服务端重传ACK、SYN
第三次握手ACK丢失：服务端重传ACK、SYN
3.为什么要进行三次握手？两次握手可以吗？
三次握手保证两点
保证双方都是双工通信
第一次握手,服务端确定客户端的发送正常
第二次握手,客户端确认服务端的收发正常
第三次握手,服务端确定客服端接收正常
如果只有第二次握手,服务端发给客服端的包丢了之后,服务端就直接建立了连接,然后一直傻等,不会释放,造成阻塞!
4.第 2 次握手传回了 ACK，为什么还要传回 SYN
ACK 是为了告诉客户端发来的数据已经接收无误，而传回 SYN 是为了把自己的初始序列号（Seq）同步给客户端,服务端请求连接。
首先ACK和SYN是合并为一个报文段发送的，由服务端发送给客户端，被动建立连接的一方（服务端）发送SYN报文主要是为了把自己的ISN（Initial Sequence Number）发送给主动建立连接的一方（客户端），并且会一直等待客户端的ACK报文，如果客户端没有回复ACK或者回复的ACK报文丢失了，服务端会持续发送SYN，直接收到客户端的ACK为止。
5.为什么要四次挥手？
释放 TCP 连接时之所以需要四次挥手，是因为 FIN 释放连接报文和 ACK 确认接收报文是分别在两次握手中传输的。 当主动方在数据传送结束后发出连接释放的通知，由于被动方可能还有必要的数据要处理，所以会先返回 ACK 确认收到报文。当被动方也没有数据再发送的时候，则发出连接释放通知，对方确认后才完全关闭TCP连接。
因为TCP是全双工的，两个方向的连接需要单独关闭。
6.CLOSE-WAIT 和 TIME-WAIT 的状态和意义
CLOSE-WAIT
是服务端发出第一次挥手(整体第二次)进入的状态,表示"我准备关闭了,但是还有自己的事情处理一下,你等我处理完"
等服务器处理好自己的数据业务,则表示我准备好了,再发送 fin 包
TIME-WAIT
是第四次挥手后,客户端进入的状态,是客户端必要的等待时间,目的是等待:1-服务端的对应端口关闭与客户端发送到服务端的数据到达(可能出现延迟),如果不存在这个步骤就会导致两个问题:
客户端立即关闭后,立即又用同样的端口握手并建立通信,此时上次的连接残留的数据包会被误认为是本次的,造成数据异常
客户端直接关闭后,若服务端重新发送 fin 包,客户端就会回应 RST,会报异常,但是其实是没有问题的
7.TIME_WAIT 状态会导致什么问题，怎么解决
我们考虑高并发短连接的业务场景，在高并发短连接的 TCP 服务器上，当服务器处理完请求后主动请求关闭连接，这样服务器上会有大量的连接处于 TIME_WAIT 状态，服务器维护每一个连接需要一个 socket，也就是每个连接会占用一个文件描述符，而文件描述符的使用是有上限的，如果持续高并发，会导致一些正常的 连接失败。
解决方案：
1.修改配置或设置 SO_REUSEADDR 套接字，使得服务器处于 TIME-WAIT 状态下的端口能够快速回收和重用。
2.用连接池解决
8.TIME-WAIT 为什么是 2MSL
当客户端发出最后的 ACK 确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完 ACK 确认报文之后，会设置一个时长为 2 MSL 的计时器。MSL（Maximum Segment Lifetime），指一段 TCP 报文在传输过程中的最大生命周期。2 MSL 即是服务器端发出 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。
若服务器在 1 MSL 内没有收到客户端发出的 ACK 确认报文，再次向客户端发出 FIN 报文。如果客户端在 2 MSL 内收到了服务器再次发来的 FIN 报文，说明服务器由于一些原因并没有收到客户端发出的 ACK 确认报文。客户端将再次向服务器发出 ACK 确认报文，并重新开始 2 MSL 的计时。
若客户端在 2MSL 内没有再次收到服务器发送的 FIN 报文，则说明服务器正常接收到客户端 ACK 确认报文，客户端可以进入 CLOSE 阶段，即完成四次挥手。
所以客户端要经历 2 MSL 时长的 TIME-WAIT 阶段，为的是确认服务器能否接收到客户端发出的 ACK 确认报文。
9.有很多 TIME-WAIT 状态如何解决
服务器可以设置 SO_REUSEADDR 套接字选项来通知内核，如果端口被占用，但 TCP 连接位于 TIME_WAIT 状态时可以重用端口。如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时 SO_REUSEADDR 选项就可以避免 TIME-WAIT 状态。
也可以采用长连接的方式减少 TCP 的连接与断开，在长连接的业务中往往不需要考虑 TIME-WAIT 状态，但其实在长连接的业务中并发量一般不会太高。
10.有很多 CLOSE-WAIT 怎么解决
首先检查是不是自己的代码问题（看是否服务端程序忘记关闭连接），如果是，则修改代码。
调整系统参数，包括句柄相关参数和 TCP/IP 的参数，一般一个 CLOSE_WAIT 会维持至少 2 个小时的时间，我们可以通过调整参数来缩短这个时间。
11.TCP 和 UDP 的区别
12.TCP 协议中的定时器
TCP中有七种计时器，分别为：
建立连接定时器：顾名思义，该定时器是在建立 TCP 连接的时候使用的，在 TCP 三次握手的过程中，发送方发送 SYN 时，会启动一个定时器（默认为 3 秒），若 SYN 包丢失了，那么 3 秒以后会重新发送 SYN 包，直到达到重传次数。
重传定时器：该计时器主要用于 TCP 超时重传机制中，当TCP 发送报文段时，就会创建特定报文的重传计时器，并可能出现两种情况：
① 若在计时器截止之前发送方收到了接收方的 ACK 报文，则撤销该计时器；
② 若计时器截止时间内并没有收到接收方的 ACK 报文，则发送方重传报文，并将计时器复位。
坚持计时器：我们知道 TCP 通过让接受方指明希望从发送方接收的数据字节数（窗口大小）来进行流量控制，当接收端的接收窗口满时，接收端会告诉发送端此时窗口已满，请停止发送数据。此时发送端和接收端的窗口大小均为0，直到窗口变为非0时，接收端将发送一个 确认 ACK 告诉发送端可以再次发送数据，但是该报文有可能在传输时丢失。若该 ACK 报文丢失，则双方可能会一直等待下去，为了避免这种死锁情况的发生，发送方使用一个坚持定时器来周期性地向接收方发送探测报文段，以查看接收方窗口是否变大。
延迟应答计时器：延迟应答也被称为捎带 ACK，这个定时器是在延迟应答的时候使用的，为了提高网络传输的效率，当服务器接收到客户端的数据后，不是立即回 ACK 给客户端，而是等一段时间，这样如果服务端有数据需要发送给客户端的话，就可以把数据和 ACK 一起发送给客户端了。
保活定时器：该定时器是在建立 TCP 连接时指定 SO_KEEPLIVE 时才会生效，当发送方和接收方长时间没有进行数据交互时，该定时器可以用于确定对端是否还活着。
FIN_WAIT_2 定时器：当主动请求关闭的一方发送 FIN 报文给接收端并且收到其对 FIN 的确认 ACK后进入 FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一端宕机等原因，导致请求方没有收到接收方发来的 FIN，主动关闭的一方会一直等待。该定时器的作用就是为了避免这种情况的发生。当该定时器超时的时候，请求关闭方将不再等待，直接释放连接。
TIME_WAIT 定时器：我们知道在 TCP 四次挥手中，发送方在最后一次挥手之后会进入 TIME_WAIT 状态，不直接进入 CLOSE 状态的主要原因是被动关闭方万一在超时时间内没有收到最后一个 ACK，则会重发最后的 FIN，2 MSL（报文段最大生存时间）等待时间保证了重发的 FIN 会被主动关闭的一段收到且重新发送最后一个 ACK 。还有一个原因是在这 2 MSL 的时间段内任何迟到的报文段会被接收方丢弃，从而防止老的 TCP 连接的包在新的 TCP 连接里面出现。
13.TCP 是如何保证可靠性的
数据分块：应用数据被分割成 TCP 认为最适合发送的数据块。
序列号和确认应答：TCP 给发送的每一个包进行编号，在传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答，即发送 ACK 报文，这个 ACK 报文当中带有对应的确认序列号，告诉发送方成功接收了哪些数据以及下一次的数据从哪里开始发。除此之外，接收方可以根据序列号对数据包进行排序，把有序数据传送给应用层，并丢弃重复的数据。
校验和： TCP 将保持它首部和数据部分的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到报文段的检验和有差错，TCP 将丢弃这个报文段并且不确认收到此报文段。
流量控制： TCP 连接的双方都有一个固定大小的缓冲空间，发送方发送的数据量不能超过接收端缓冲区的大小。当接收方来不及处理发送方的数据，会提示发送方降低发送的速率，防止产生丢包。TCP 通过滑动窗口协议来支持流量控制机制。
拥塞控制： 当网络某个节点发生拥塞时，减少数据的发送。
ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
超时重传： 当 TCP 发出一个报文段后，它启动一个定时器，等待目的端确认收到这个报文段。如果超过某个时间还没有收到确认，将重发这个报文段。
