Net

最新推荐文章于 2022-11-17 21:34:08 发布

CW96

最新推荐文章于 2022-11-17 21:34:08 发布

阅读量774

点赞数

分类专栏：计算机网络

本文链接：https://blog.csdn.net/MARSHCW/article/details/116529599

版权

计算机网络专栏收录该内容

1 篇文章 0 订阅

订阅专栏

简述

OSI 模型全称为开放式通信系统互连参考模型，是国际标准化组织 ( ISO ) 提出的一个试图使各种计算机在世界范围内互连为网络的标准框架。 OSI 将计算机网络体系结构划分为七层，每一层实现各自的功能和协议，并完成与相邻层的接口通信。OSI 的服务定义详细说明了各层所提供的服务。某一层的服务就是该层及其下各层的一种能力，它通过接口提供给更高一层。各层所提供的服务与这些服务是怎么实现的无关。

① 应用层

应用层位于 OSI 参考模型的第七层，其作用是通过应用程序间的交互来完成特定的网络应用。该层协议定义了应用进程之间的交互规则，通过不同的应用层协议为不同的网络应用提供服务。例如域名系统 DNS，支持万维网应用的 HTTP 协议，电子邮件系统采用的 SMTP 协议等。在应用层交互的数据单元我们称之为报文。

② 表示层

表示层的作用是使通信的应用程序能够解释交换数据的含义，其位于 OSI 参考模型的第六层，向上为应用层提供服务，向下接收来自会话层的服务。该层提供的服务主要包括数据压缩，数据加密以及数据描述。这使得应用程序不必担心在各台计算机中表示和存储的内部格式差异。

③ 会话层

会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层提供了数据交换的定界和同步功能，包括了建立检查点和恢复方案的方法。

④ 传输层

传输层的主要任务是为主机进程之间的通信提供服务。应用程序利用该服务传送应用层报文。该服务并不针对某一特定的应用，多种应用可以使用同一个传输层服务。由于一台主机可同时运行多个线程，因此传输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面传输层的服务，分用和复用相反，是传输层把收到的信息分别交付上面应用层中的相应进程。传输单位是报文段（TCP）或用户数据报（UDP）。

⑤ 网络层

两台计算机之间传送数据时其通信链路往往不止一条，所传输的信息甚至可能经过很多通信子网。网络层的主要任务就是选择合适的网间路由和交换节点，确保数据按时成功传送。在发送数据时，网络层把传输层产生的报文或用户数据报封装成分组和包向下传输到数据链路层。在网络层使用的协议是无连接的网际协议（Internet Protocol）和许多路由协议，因此我们通常把该层简单地称为 IP 层。传输单位是数据报。

⑥ 数据链路层

数据链路层通常也叫做链路层，在物理层和网络层之间。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层协议。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息。通过控制信息我们可以知道一个帧的起止比特位置，此外，也能使接收端检测出所收到的帧有无差错，如果发现差错，数据链路层能够简单的丢弃掉这个帧，以避免继续占用网络资源。传输单位是帧。

⑦ 物理层

作为 OSI 参考模型中最低的一层，物理层的作用是实现计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。该层的主要任务是确定与传输媒体的接口的一些特性（机械特性、电气特性、功能特性，过程特性）。传输单位是比特。

从上往下依次为：

应用层->表示层->会话层->传输层->网络层->数据链路层->物理层

在这里插入图片描述

数据如何在各层之间传输【数据的封装过程】

在发送主机端，一个应用层报文被传送到运输层。在最简单的情况下，运输层收取到报文并附上附加信息，该首部将被接收端的运输层使用。应用层报文和运输层首部信息一道构成了运输层报文段。附加的信息可能包括：允许接收端运输层向上向适当的应用程序交付报文的信息以及差错检测位信息。该信息让接收端能够判断报文中的比特是否在途中已被改变。运输层则向网络层传递该报文段，网络层增加了如源和目的端系统地址等网络层首部信息，生成了网络层数据报。该数据报接下来被传递给链路层，在数据链路层数据包添加发送端 MAC 地址和接收端 MAC 地址后被封装成数据帧，在物理层数据帧被封装成比特流，之后通过传输介质传送到对端。

在这里插入图片描述

TCP/IP 参考模型

TCP/IP 参考模型直接面向市场需求，实现起来也比较容易，因此在一经提出便得到了广泛的应用。基于 TCP/IP 的参考模型将协议分成四个层次，如上图所示，它们分别是：网络访问层、网际互联层、传输层、和应用层。

① 应用层

TCP/IP 模型将 OSI 参考模型中的会话层、表示层和应用层的功能合并到一个应用层实现，通过不同的应用层协议为不同的应用提供服务。例如：FTP、Telnet、DNS、SMTP 等。

② 传输层

该层对应于 OSI 参考模型的传输层，为上层实体提供源端到对端主机的通信功能。传输层定义了两个主要协议：传输控制协议（TCP）和用户数据报协议（UDP）。其中面向连接的 TCP 协议保证了数据的传输可靠性，面向无连接的 UDP 协议能够实现数据包简单、快速地传输。

③ 网际互联层

网际互联层对应 OSI 参考模型的网络层，主要负责相同或不同网络中计算机之间的通信。在网际互联层， IP 协议提供的是一个不可靠、无连接的数据报传递服务。该协议实现两个基本功能：寻址和分段。根据数据报报头中的目的地址将数据传送到目的地址，在这个过程中 IP 负责选择传送路线。除了 IP 协议外，该层另外两个主要协议是互联网组管理协议（IGMP）和互联网控制报文协议（ICMP）。

④ 网络接入层

网络接入层的功能对应于 OSI 参考模型中的物理层和数据链路层，它负责监视数据在主机和网络之间的交换。事实上，TCP/IP 并未真正描述这一层的实现，而由参与互连的各网络使用自己的物理层和数据链路层协议，然后与 TCP/IP 的网络接入层进行连接，因此具体的实现方法将随着网络类型的不同而有所差异。

OSI 模型和 TCP/IP 模型异同比较

相同点

① OSI 参考模型与 TCP/IP 参考模型都采用了层次结构。

② 都能够提供面向连接和无连接两种通信服务机制。

不同点

① OSI 采用的七层模型； TCP/IP 是四层结构。

② TCP/IP 参考模型没有对网络接口层进行细分，只是一些概念性的描述； OSI 参考模型对服务和协议做了明确的区分。

③ OSI 先有模型，后有协议规范，适合于描述各种网络；TCP/IP 是先有协议集然后建立模型，不适用于非 TCP/IP 网络。

④ TCP/IP 一开始就提出面向连接和无连接服务，而 OSI 一开始只强调面向连接服务，直到很晚才开始制定无连接的服务标准。

⑤ OSI 参考模型虽然被看好，但将网络划分为七层，实现起来较困难；相反，TCP/IP 参考模型虽然有许多不尽人意的地方，但作为一种简化的分层结构还是比较成功的。

OSI 和 TCP/IP 协议之间的对应关系

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nYQhooBO-1620458727935)(C:\Users\bj\AppData\Roaming\Typora\typora-user-images\image-20210507101818576.png)]$

为什么 TCP/IP 去除了表示层和会话层

OSI 参考模型在提出时，他们的理想是非常好的，但实际上，由于会话层、表示层、应用层都是在应用程序内部实现的，最终产出的是一个应用数据包，而应用程序之间是几乎无法实现代码的抽象共享的，这也就造成 OSI 设想中的应用程序维度的分层是无法实现的，例如，我们几乎不会认为数据的压缩、加密算法算是一种协议，而会话的概念则更为抽象，难以用协议来进行描述，所以在后来的 TCP/IP 协议框架的设计中，便将表示层和会话层与应用层整合在一起，让整个过程更为清晰明了。

应用层

有连接，无连接，可靠协议，不可靠，有状态，无状态的区别?

不可靠：不能保证数据安全准确的传输给对方，提供“尽力而为”的交付服务。
可靠：保证数据安全准确的传输给对方。
有连接：数据发送方与数据接收方需要建立对话并维持该来连接。
无连接：数据发送方与数据接收方不需要建立对话并维持该连接。
有状态：对于事务处理拥有记忆能力，对于之前处理过的事务保留其信息。
无状态：对于事务处理没有记忆能力，对于之前处理过的事务不再保留其信息。对于HTTP而言，服务器不会保存关于客户的信息。

简述HTTP协议?

HTTP（超文本传输协议）是应用层上的一种基于C/S架构的无连接无状态的请求/响应模式通信协议。

HTTP有请求报文和响应报文两种形式。

请求报文

在这里插入图片描述

请求报文由三个部分组成：

请求行 + 请求头 + 请求实体

1. 请求行：请求方法，URL，协议版本

1.1 请求方法

GET：重点在于从服务器上获取资源。

POST: 重点在于向服务器发送数据（例如提交表单或上传文件）

HEAD: 类似于GET请求，不过返回的响应报文中没有响应体承载数据，只用于获取响应报头。

1.2 URL：统一资源定位符

在这里插入图片描述

1.3 协议版本

有HTTP1.0 ， HTTP1.1， HTTPS 等协议

请求头

通过键值对的方式存储。常见的如Content-Type（请求体/响应体的类型），Content-Length（请求体/响应体的长度），Content-Encoding（请求体/响应体的编码格式）

空行

用于区分请求体

请求实体

用于存放实际的数据

响应报文

在这里插入图片描述

响应报文同样分为三个部分：
状态行 + 响应头 + 响应实体

1. 状态行

1.1 协议版本

一般跟请求报文对应的协议版本相同，有HTTP1.0，HTTP1.1，HTTPS。

1.2 状态码

HTTP状态码有五种类型，如下：

1**：提示信息，服务器收到请求，要求请求者继续操作；

2**：成功，操作成功接收并处理；200 OK：客户端请求成功；

3**：重定向，需要进一步的操作以完成请求；301：网页被永久转移到其他URL；302：网页临时跳转。

4**：客户端错误，请求包含语法错误或无法完成请求；400 Bad Request：客户端请求有语法错误，不能被服务器所理解；401 Unauthorized：请求未经授权；404：请求资源不存在，可能输入了错误的URL。

5**：服务器错误，服务器在处理请求的过程中发生了错误。500：服务器内部发生了不可预期的错误；503 Server Unavailable：服务器当前不能处理客户端的请求。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SuirJg27-1620458727937)(C:\Users\bj\AppData\Roaming\Typora\typora-user-images\image-20210507105008485.png)]$

200 请求成功
204 请求成功但无内容返回
206 范围请求成功

301 永久重定向； 30(2|3|7)临时重定向，语义和实现有略微区别；
304 带if-modified-since 请求首部的条件请求，条件没有满足

400 语法错误（前端挨打）
401 需要认证信息
403 拒绝访问
404 找不到资源
412 除if-modified-since 以外的条件请求，条件未满足

500 服务器内部发生了不可预期的错误；

501 Not Implemented 服务器不支持当前请求所需要的某个功能

503 服务器宕机了（DevOps or IT 挨打）

1.3 状态码信息

如 200 OK，404 NOT FOUND。

响应头

一般以键值对的方式进行存储。常见的如Content-Type（请求体/响应体的类型），Content-Length（请求体/响应体的长度），Content-Encoding（请求体/响应体的编码格式）。

空行

用于划分开响应头和响应体。

响应实体

用于存放响应数据。

请求报文与响应报文样例

请求报文GET

在这里插入图片描述

请求报文 POST

在这里插入图片描述

响应报文返回json字符串

在这里插入图片描述

响应报文 HTML

在这里插入图片描述

301和302状态码的区别？

301（Moved Permanently）状态码代表网页被永久转移到其他URL；302（Found）状态码代表网页被暂时转移到其他URL。

GET和POST有什么区别？

解答一：

GET一般在从服务器获取数据；POST一般在于向服务器发送数据。
GET和POST都能够使用额外的参数，GET的参数出现在URL之中并用？隔开，参数之间用&相连，是可见的；POST提交的数据是放在请求体中，是不可见的。
GET传输数据时会有安全问题，在提交数据时用户名和密码都会出现在URL上面，黑客可以轻松获得；而POST方法提交的数据由于是存放在请求体中，不会被显示。
GET传输数据大小有限制（因为浏览器对URL长度有限制）；POST方法传输的数据没有限制。

解答二：

get 提交的数据会放在 URL 之后，并且请求参数会被完整的保留在浏览器的记录里，由于参数直接暴露在 URL 中，可能会存在安全问题，因此往往用于获取资源信息。而 post 参数放在请求主体中，并且参数不会被保留，相比 get 方法，post 方法更安全，主要用于修改服务器上的资源。
get 请求只支持 URL 编码，post 请求支持多种编码格式。
get 只支持 ASCII 字符格式的参数，而 post 方法没有限制。
get 提交的数据大小有限制（这里所说的限制是针对浏览器而言的），而 post 方法提交的数据没限制。
get 方式需要使用 Request.QueryString 来取得变量的值，而 post 方式通过 Request.Form 来获取。
get 方法产生一个 TCP 数据包，post 方法产生两个（并不是所有的浏览器中都产生两个）。

post请求的过程：

1.浏览器请求tcp连接（第一次握手）

2.服务器答应进行tcp连接（第二次握手）

3.浏览器确认，并发送post请求头（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）

4.服务器返回100 continue响应

5.浏览器开始发送数据

6.服务器返回200 ok响应

get请求的过程

1.浏览器请求tcp连接（第一次握手）

2.服务器答应进行tcp连接（第二次握手）

3.浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）

4.服务器返回200 ok响应

GET 和 POST样例补充

在这里插入图片描述

GET 的长度限制是多少

HTTP 中的 GET 方法是通过 URL 传递数据的，而 URL 本身并没有对数据的长度进行限制，真正限制 GET 长度的是浏览器，例如 IE 浏览器对 URL 的最大限制为 2000多个字符，大概 2KB左右，像 Chrome, FireFox 等浏览器能支持的 URL 字符数更多，其中 FireFox 中 URL 最大长度限制为 65536 个字符，Chrome 浏览器中 URL 最大长度限制为 8182 个字符。并且这个长度不是只针对数据部分，而是针对整个 URL 而言，在这之中，不同的服务器同样影响 URL 的最大长度限制。因此对于特定的浏览器，GET的长度限制不同。

由于 POST 方法请求参数在请求主体中，理论上讲，post 方法是没有大小限制的，而真正起限制作用的是服务器处理程序的处理能力。

HTTP 方法(method)了解哪些

HTTP/1.0 定义了三种请求方法：GET, POST 和 HEAD 方法。

HTTP/1.1 增加了六种请求方法：OPTIONS, PUT, PATCH, DELETE, TRACE 和 CONNECT 方法。

方法	描述
GET	请求指定的页面信息，并返回具体内容，通常只用于读取数据。
HEAD	类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头。
POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立或已有资源的更改。
PUT	替换指定的资源，没有的话就新增。
DELETE	请求服务器删除 URL 标识的资源数据。
CONNECT	将服务器作为代理，让服务器代替用户进行访问
OPTIONS	向服务器发送该方法，会返回对指定资源所支持的 HTTP 请求方法。
TRACE	回显服务器收到的请求数据，即服务器返回自己收到的数据，主要用于测试和诊断。
PATCH	是对 PUT 方法的补充，用来对已知资源进行局部更新。

为什么 fidder，charles 能抓到你的包【抓取数据包的过程】

假如我们需要抓取客户端的数据包，需要监控客户端与服务器交互之间的网络节点，监控其中任意一个网络节点（网卡），获取所有经过网卡中的数据，对这些数据按照网络协议进行解析，这就是抓包的基本原理。而中间的网络节点不受我们控制，是基本无法实现抓包的，因此只能在客户端与服务器之间进行抓包。

① 当采用抓包工具抓取 HTTP 数据包时，过程较为简单：

首先抓包工具会提出代理服务，客户端需要连接该代理；
客户端发出 HTTP 请求时，会经过抓包工具的代理，抓包工具将请求的原文进行展示；
抓包工具使用该原文将请求发送给服务器；
服务器返回结果给抓包工具，抓包工具将返回结果进行展示；
抓包工具将服务器返回的结果原样返回给客户端。

这里抓包工具相当于透明人，数据经过的时候它一只手接到数据，然后另一只手把数据传出去。

② 当抓取 HTTPS 数据包时：

客户端连接抓包工具提供的代理服务，并安装抓包工具的根证书；
客户端发出 HTTPS 请求，抓包工具模拟服务器与客户端进行 TLS 握手交换密钥等流程；
抓包工具发送一个 HTTPS 请求给客户端请求的目标服务器，并与目标服务器进行 TLS 握手交换密钥等流程；
客户端使用与抓包工具协定好的密钥加密数据后发送给抓包工具；
抓包工具使用与客户端协定好的密钥解密数据，并将结果进行展示；
抓包工具将解密后的客户端数据，使用与服务器协定好的密钥进行加密后发送给目标服务器；
服务器解密数据后，做对应的逻辑处理，然后将返回结果使用与抓包工具协定好的密钥进行加密发送给抓包工具；
抓包工具将服务器返回的结果，用与服务器协定好的密钥解密，并将结果进行展示；
抓包工具将解密后的服务器返回数据，使用与客户端协定好的密钥进行加密后发送给客户端；
客户端解密数据。

这个时候抓包工具对客户端来说相当于服务器，对服务器来说相当于客户端。在这个传输过程中，客户端会以为它就是目标服务器，服务器也会以为它就是请求发起的客户端。

socket() 套接字有哪些

套接字（Socket）是对网络中不同主机上的应用进程之间进行双向通信的端点的抽象，网络进程通信的一端就是一个套接字，不同主机上的进程便是通过套接字发送报文来进行通信。例如 TCP 用主机的 IP 地址 + 端口号作为 TCP 连接的端点，这个端点就叫做套接字。

套接字主要有以下三种类型：

流套接字（SOCK_STREAM）：流套接字基于 TCP 传输协议，主要用于提供面向连接、可靠的数据传输服务。由于 TCP 协议的特点，使用流套接字进行通信时能够保证数据无差错、无重复传送，并按顺序接收，通信双方不需要在程序中进行相应的处理。
数据报套接字（SOCK_DGRAM）：和流套接字不同，数据报套接字基于 UDP 传输协议，对应于无连接的 UDP 服务应用。该服务并不能保证数据传输的可靠性，也无法保证对端能够顺序接收到数据。此外，通信两端不需建立长时间的连接关系，当 UDP 客户端发送一个数据给服务器后，其可以通过同一个套接字给另一个服务器发送数据。当用 UDP 套接字时，丢包等问题需要在程序中进行处理。
原始套接字（SOCK_RAW）：由于流套接字和数据报套接字只能读取 TCP 和 UDP 协议的数据，当需要传送非传输层数据包（例如 Ping 命令时用的 ICMP 协议数据包）或者遇到操作系统无法处理的数据包时，此时就需要建立原始套接字来发送。

一个URL（统一资源路径地址）包含哪些部分呢？

举个例子，比如 “http://www.baidu.com/index.html?name=mo&age=25#dowell”，在这个例子中我们可以分成六部分；

1、传输协议：http，https

2、域名：例www.baidu.com为网站名字。 baidu.com为一级域名，www是服务器

3、端口：不填写的话默认走的是80端口号

4、路径 http://www.baidu.com/路径1/路径1.2。/表示根目录

5、携带的参数：？name=mo

6、哈希值：#dowell

从输入URL到页面加载发生了什么？（HTTP的工作原理？）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mzaHUOCX-1620458727940)(C:\Users\bj\AppData\Roaming\Typora\typora-user-images\image-20210507103148297.png)]

浏览器向DNS（Domain Name Server,端口号为：53）请求，DNS将域名转换为对应的IP地址。此时采用的是UDP传输协议。
浏览器连接到Web服务器HTTP/80端口，三次握手创建TCP连接。
浏览器发送HTTP请求，读取URL域名后面对应文件，并注意该请求作为TCP三次握手中的第三次握手的数据发送给Web服务器。
服务器接收HTTP请求并返回HTTP响应，响应体中存放对应的html文本。
如果CONNECITON模式为close，立刻四次挥手释放TCP连接；若CONNECTION模式为keep-alive，则保持该连接一段时间后再释放，这段时间内还可以接受请求。
浏览器解析html文本内容并显示。

DNS 为什么用 UDP

更正确的答案是 DNS 既使用 TCP 又使用 UDP。

当进行区域传送（主域名服务器向辅助域名服务器传送变化的那部分数据）时会使用 TCP，因为数据同步传送的数据量比一个请求和应答的数据量要多，而 TCP 允许的报文长度更长，因此为了保证数据的正确性，会使用基于可靠连接的 TCP。

当客户端向 DNS 服务器查询域名 ( 域名解析) 的时候，一般返回的内容不会超过 UDP 报文的最大长度，即 512 字节。用 UDP 传输时，不需要经过 TCP 三次握手的过程，从而大大提高了响应速度，但这要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。

DNS 的作用和原理

DNS

DNS（Domain Name System）是域名系统的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，用于 TCP/IP 网络。

DNS 的作用

通常我们有两种方式识别主机：通过主机名或者 IP 地址。人们喜欢便于记忆的主机名表示，而路由器则喜欢定长的、有着层次结构的 IP 地址。为了满足这些不同的偏好，我们就需要一种能够进行主机名到 IP 地址转换的目录服务，域名系统作为将域名和 IP 地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。

DNS 域名解析原理

DNS 采用了分布式的设计方案，其域名空间采用一种树形的层次结构：

在这里插入图片描述

上图展示了 DNS 服务器的部分层次结构，从上到下依次为根域名服务器、顶级域名服务器和权威域名服务器。其实根域名服务器在因特网上有13个，大部分位于北美洲。第二层为顶级域服务器，这些服务器负责顶级域名（如 com、org、net、edu）和所有国家的顶级域名（如uk、fr、ca 和 jp）。在第三层为权威 DNS 服务器，因特网上具有公共可访问主机（例如 Web 服务器和邮件服务器）的每个组织机构必须提供公共可访问的 DNS 记录，这些记录由组织机构的权威 DNS 服务器负责保存，这些记录将这些主机的名称映射为 IP 地址。

除此之外，还有一类重要的 DNS 服务器，叫做本地 DNS 服务器。本地 DNS 服务器严格来说不在 DNS 服务器的层次结构中，但它对 DNS 层次结构是很重要的。一般来说，每个网络服务提供商（ISP）都有一台本地 DNS 服务器。当主机与某个 ISP 相连时，该 ISP 提供一台主机的 IP 地址，该主机具有一台或多台其本地 DNS 服务器的 IP 地址。主机的本地 DNS 服务器通常和主机距离较近，当主机发起 DNS 请求时，该请求被发送到本地 DNS 服务器，它起着代理的作用，并将该请求转发到 DNS 服务器层次结构中。

我们以一个例子来了解 DNS 的工作原理，假设主机 A（IP 地址为 abc.xyz.edu）想知道主机 B 的 IP 地址（def.mn.edu），如下图所示，主机 A 首先向它的本地 DNS 服务器发送一个 DNS 查询报文。该查询报文含有被转换的主机名 def.mn.edu。本地 DNS 服务器将该报文转发到根 DNS 服务器，根 DNS 服务器注意到查询的 IP 地址前缀为 edu 后向本地 DNS 服务器返回负责 edu 的顶级域名服务器的 IP 地址列表。该本地 DNS 服务器则再次向这些顶级域名服务器发送查询报文。该顶级域名服务器注意到 mn.edu 的前缀，并用权威域名服务器的 IP 地址进行响应。通常情况下，顶级域名服务器并不总是知道每台主机的权威 DNS 服务器的 IP 地址，而只知道中间的某个服务器，该中间 DNS 服务器依次能找到用于相应主机的 IP 地址，我们假设中间经历了权威服务器 ① 和 ②，最后找到了负责 def.mn.edu 的权威 DNS 服务器 ③，之后，本地 DNS 服务器直接向该服务器发送查询报文从而获得主机 B 的IP 地址。

在这里插入图片描述

在上图中，IP 地址的查询其实经历了两种查询方式，分别是递归查询和迭代查询。

拓展：域名解析查询的两种方式

递归查询：如果主机所询问的本地域名服务器不知道被查询域名的 IP 地址，那么本地域名服务器就以 DNS 客户端的身份，向其他根域名服务器继续发出查询请求报文，即替主机继续查询，而不是让主机自己进行下一步查询，如上图步骤（1）和（10）。
迭代查询：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器下一步应该找哪个域名服务器进行查询，然后让本地服务器进行后续的查询，如上图步骤（2）~（9）。

怎么实现 DNS 劫持

DNS 劫持即域名劫持，是通过将原域名对应的 IP 地址进行替换从而使得用户访问到错误的网站或者使得用户无法正常访问网站的一种攻击方式。域名劫持往往只能在特定的网络范围内进行，范围外的 DNS 服务器能够返回正常的 IP 地址。攻击者可以冒充原域名所属机构，通过电子邮件的方式修改组织机构的域名注册信息，或者将域名转让给其它组织，并将新的域名信息保存在所指定的 DNS 服务器中，从而使得用户无法通过对原域名进行解析来访问目的网址。

具体实施步骤如下：

① 获取要劫持的域名信息：攻击者首先会访问域名查询站点查询要劫持的域名信息。

② 控制域名相应的 E-MAIL 账号：在获取到域名信息后，攻击者通过暴力破解或者专门的方法破解公司注册域名时使用的 E-mail 账号所对应的密码。更高级的攻击者甚至能够直接对 E-mail 进行信息窃取。

③ 修改注册信息：当攻击者破解了 E-MAIL 后，会利用相关的更改功能修改该域名的注册信息，包括域名拥有者信息，DNS 服务器信息等。

④ 使用 E-MAIL 收发确认函：在修改完注册信息后，攻击者在 E-mail 真正拥有者之前收到修改域名注册信息的相关确认信息，并回复确认修改文件，待网络公司恢复已成功修改信件后，攻击者便成功完成 DNS 劫持。

用户端的一些预防手段：

直接通过 IP 地址访问网站，避开 DNS 劫持。
由于域名劫持往往只能在特定的网络范围内进行，因此一些高级用户可以通过网络设置让 DNS 指向正常的域名服务器以实现对目的网址的正常访问，例如将计算机首选 DNS 服务器的地址固定为 8.8.8.8。

HTTP/3 了解吗

HTTP/2 存在的问题

我们知道，传统 Web 平台的数据传输都基于 TCP 协议，而 TCP 协议在创建连接之前不可避免的需要三次握手，如果需要提高数据交互的安全性，即增加传输层安全协议（TLS），还会增加更多的握手次数。 HTTP 从 1.0 到 2.0，其传输层都是基于 TCP 协议的。即使是带来巨大性能提升的 HTTP/2，也无法完全解决 TCP 协议存在的固有问题（慢启动，拥塞窗口尺寸的设置等）。此外，HTTP/2 多路复用只是减少了连接数，其队头的拥塞问题并没有完全解决，倘若 TCP 丢包率过大，则 HTTP/2 的表现将不如 HTTP/1.1。

QUIC 协议

QUIC（Quick UDP Internet Connections），直译为快速 UDP 网络连接，是谷歌制定的一种基于 UDP 的低延迟传输协议。其主要目的是解决采用传输层 TCP 协议存在的问题，同时满足传输层和应用层对多连接、低延迟等的需求。该协议融合了 TCP, TLS, HTTP/2 等协议的特性，并基于 UDP传输。该协议带来的主要提升有：

低延迟连接。当客户端第一次连接服务器时，QUIC 只需要 1 RTT（Round-Trid Time）延迟就可以建立安全可靠的连接（采用 TLS 1.3 版本），相比于 TCP + TLS 的 3 次 RTT 要更加快捷。之后，客户端可以在本地缓存加密的认证信息，当再次与服务器建立连接时可以实现 0 RTT 的连接建立延迟。
QUIC 复用了 HTTP/2 协议的多路复用功能，由于 QUIC 基于 UDP，所以也避免了 HTTP/2存在的队头阻塞问题。
基于 UDP 协议的 QUIC 运行在用户域而不是系统内核，这使得 QUIC 协议可以快速的更新和部署，从而很好地解决了 TPC 协议部署及更新的困难。
QUIC 的报文是经过加密和认证的，除了少量的报文，其它所有的 QUIC 报文头部都经过了认证，报文主体经过了加密。只要有攻击者篡改 QUIC 报文，接收端都能及时发现。
具有向前纠错机制，每个数据包携带了除了本身内容外的部分其他数据包的内容，使得在出现少量丢包的情况下，尽量地减少其它包的重传次数，其通过牺牲单个包所携带的有效数据大小换来更少的重传次数，这在丢包数量较小的场景下能够带来一定程度的性能提升。

HTTP/3

HTTP/3 是在 QUIC 基础上发展起来的，其底层使用 UDP 进行数据传输，上层仍然使用 HTTP/2。在 UDP 与 HTTP/2 之间存在一个 QUIC 层，其中 TLS 加密过程在该层进行处理。HTTP/3 主要有以下几个特点：

① 使用 UDP 作为传输层进行通信；

② 在 UDP 之上的 QUIC 协议保证了 HTTP/3 的安全性。QUIC 在建立连接的过程中就完成了 TLS 加密握手；

③ 建立连接快，正常只需要 1 RTT 即可建立连接。如果有缓存之前的会话信息，则直接验证和建立连接，此过程 0 RTT。建立连接时，也可以带有少量业务数据；

④ 不和具体底层连接绑定，QUIC 为每个连接的两端分别分配了一个唯一 ID，上层连接只认这对逻辑 ID。网络切换或者断连时，只需要继续发送数据包即可完成连接的建立；

⑤ 使用 QPACK 进行头部压缩，因为在 HTTP/2 中的 HPACK 要求传输过程有序，这会导致队头阻塞，而 QPACK 不存在这个问题。

最后我们使用一张图来清晰的表示出 HTTP 协议的发展变化：
在这里插入图片描述

数字证书认证机构申请

服务器端的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名;
客户端向服务器端发出请求时，服务器返回证书文件;
客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
客户端还会验证证书相关的域名信息、有效时间等信息；客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应CA的证书，证书也会被判定非法。

在这里插入图片描述

HTTPS 的工作方式

HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer）是以安全为目标的 HTTP 协议，在 HTTP 的基础上通过传输加密和身份认证的方式保证了传输过程的安全性。

其工作流程如下：
① 客户端发起一个 HTTPS 请求，并连接到服务器的【 443 端口】，发送的信息主要包括自身所支持的算法列表和密钥长度等。
② 服务端将自身所支持的所有加密算法与客户端的算法列表进行对比并选择一种支持的加密算法，然后将它和其它密钥组件一同发送给客户端。
③ 服务器向客户端发送一个包含【数字证书的报文】，该数字证书中包含证书的颁发机构、过期时间、服务端的公钥等信息。
④ 最后服务端发送一个完成报文通知客户端SSL的第一阶段已经协商完成。
⑤ SSL 第一次协商完成后，客户端发送一个回应报文，报文中包含一个客户端生成的【随机密码串】，称为 pre_master_secre，并且该报文是经过证书中的公钥加密过的。
⑥ 紧接着客户端会发送一个报文提示服务端在此之后的报文是采用pre_master_secre 加密的。
⑦ 客户端向服务端发送一个 finish 报文，这次握手中包含第一次握手至今所有报文的整体校验值，最终协商是否完成取决于服务端能否成功解密。
⑧ 服务端同样发送与第 ⑥ 步中相同作用的报文，已让客户端进行确认，最后发送 finish 报文告诉客户端自己能够【正确解密报文】。

当服务端和客户端的 finish 报文交换完成之后，SSL 连接就算建立完成了，之后就进行和 HTTP 相同的通信过程，唯一不同的是在 HTTP 通信过程中并不是采用明文传输，而是采用对称加密的方式，其中对称密钥已经在 SSL 的建立过程中协商好了。
在这里插入图片描述

HTTP长连接和短连接的区别？

长连接
CONNECTION字段设置为keep-alive，在建立连接，传输数据之后，并不会马上断开连接，而是等待一段时间之后再断开，这段时间可以再多次传输数据。
短连接
CONNECTION字段设置为closed，在建立连接，传输数据之后，立刻断开连接。会有较大的开销。

补充：
1.HTTP1.0默认使用短连接，HTTP1.1默认使用长连接。
2.长连接分为流水线方式和非流水线方式，非流水线方式就是在接收到HTTP的下一次响应之前都不能再发送新的请求报文，流水线方式就是在接收到HTTP下一次响应报文之前都可以发送新的请求报文。

应用场景

**长连接：**多用于操作频繁，点对点的通讯，而且客户端连接数目较少的情况。例如即时通讯、网络游戏等。
**短连接：**用户数目较多的Web网站的 HTTP 服务一般用短连接。例如京东，淘宝这样的大型网站一般客户端数量达到千万级甚至上亿，若采用长连接势必会使得服务端大量的资源被无效占用，所以一般使用的是短连接。

Keep-Alive和非Keep-Alive区别

HTTP/1.0中，浏览器每次发起请求就要与服务器创建一个新的TCP连接，服务器完成请求处理后立即断开tcp连接，服务器不会跟踪客户也不会记录过去的请求。TCP连接的创建和断开需要消耗资源和时间，为了减少资源和时间消耗，就需要对重用连接。HTTP/1.1版本默认使用持久连接，之前的版本是使用的是非持久，想要持久就需要指定connection首部字段的值为keep-alive，来告诉对方当前请求响应完毕后不要关闭连接。
对于非keep-alive，就必须为每个请求的对象建立和维护一个全新的连接。每次建立连接就需要分配缓冲区和变量，这样会给服务器带来负担。在keep-alive方式下，服务器在响应后还继续保持连接，可以继续连接传输数据。甚至位于同一服务器的多个web页面从该服务器发送到同一个客户机时，可以在单个持久TCP连接上进行。
keep-alive也会在某种程度上造成资源浪费，所以要正确设置keep-alive timeout参数t，当TCP连接在传送完最后一个HTTP响应，会再将连接保持t秒，t秒后关闭连接释放资源。

长连接和短连接.png

怎么知道 HTTP 的报文长度

当响应消息中存在 Content-Length 字段时，我们可以直接根据这个值来判断数据是否接收完成。
例如客户端向服务器请求一个静态页面或者一张图片时，服务器能够很清楚的知道请求内容的大小，因此可以通过消息首部字段 Content- Length 来告诉客户端需要接收多少数据，但是如果服务器预先不知道请求内容的大小，例如加载动态页面的时候，就需要使用 Transfer-Encoding: chunked 的方式来代替 Content-Length。
分块传输编码（Chunked transfer encoding）是 HTTP/1.1 中引入的一种数据传输机制，其允许 HTTP 由服务器发送给客户端的数据可以分成多个部分，当数据分解成一系列数据块发送时，服务器就可以发送数据而不需要预先知道发送内容的总大小，每一个分块包含十六进制的长度值和数据，最后一个分块长度值为0，表示实体结束，客户机可以以此为标志确认数据已经接收完毕。

HTTP是不保存状态的协议，那么如何保存用户的状态？（Cookie，Session的区别是什么？）

使用Cookie 和Session。

1.Cookie的工作原理
（1）浏览器端第一次发送请求到服务器端
（2）服务器端创建Cookie，该Cookie中包含用户的信息，然后将该Cookie发送到浏览器端
（3）浏览器端再次访问服务器端时会携带服务器端创建的Cookie
（4）服务器端通过Cookie中携带的数据区分不同的用户
在这里插入图片描述

2.Session的工作原理
（1）浏览器端第一次发送请求到服务器端，服务器端创建一个Session，同时会创建一个特殊的Cookie（name为JSESSIONID的固定值，value为session对象的ID），然后将该Cookie发送至浏览器端
（2）浏览器端发送第N（N>1）次请求到服务器端,浏览器端访问服务器端时就会携带该name为JSESSIONID的Cookie对象
（3）服务器端根据name为JSESSIONID的Cookie的value(sessionId),去查询Session对象，从而区分不同用户。
name为JSESSIONID的Cookie不存在（关闭或更换浏览器），返回1中重新去创建Session与特殊的Cookie
name为JSESSIONID的Cookie存在，根据value中的SessionId去寻找session对象
value为SessionId不存在**（Session对象默认存活30分钟）**，返回1中重新去创建Session与特殊的Cookie
value为SessionId存在，返回session对象
Session的工作原理图

在这里插入图片描述

如果Cookie被禁用怎么办？

可用将URL重写，也就是将SessionID直接附加在URL路径的后面。

影响一个HTTP网络请求的因素

带宽
延迟

HTTP1.0 和 HTTP1.1的主要区别是什么？

√长短连接

HTTP1.0默认使用短连接；HTTP1.1默认使用长连接，减少了建立和关闭连接的消耗和延迟。
√节约带宽
HTTP1.0中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。
√错误状态响应码

在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
√缓存控制策略

在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
断点续传功能

HTTP1.1中请求头中引入了range，可以只请求资源的某个部分，实现断点续传。
HOST域

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。

HTTP1.1和HTTP2.0的区别

相比于 HTTP/1.X 的文本（字符串）传送， HTTP/2.0 采用二进制传送。

客户端和服务器传输数据时把数据分成帧，帧组成了数据流，流具有流 ID 标识和优先级，通过优先级以及流依赖能够一定程度上解决关键请求被阻塞的问题。
多路复用

HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

头部数据压缩

在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。

HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

服务器推送

服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。

为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。

URI和URL的区别是什么？

URI
统一资源标识符（Uniform Resource Identifier），在某一种规则下能唯一的标识出一个资源。
URL
统一资源定位符（Uniform Resource Location），用定位的方式唯一的标识出一个资源。

URL就是用定位方式实现的URI。

URL，即统一资源定位符 (Uniform Resource Locator )，URL 其实就是我们平时上网时输入的网址，它标识一个互联网资源，并指定对其进行操作或获取该资源的方法。例如 https://leetcode-cn.com/problemset/all/ 这个 URL，标识一个特定资源并表示该资源的某种形式是可以通过 HTTP 协议从相应位置获得。

从定义即可看出，URL 是 URI 的一个子集，两者都定义了资源是什么，而 URL 还定义了如何能访问到该资源。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。简单地说，只要能唯一标识资源的就是 URI，在 URI 的基础上给出其资源的访问方式的就是 URL。

HTTP 和 HTTPS的区别是什么？

HTTP 协议以【明文方式】发送内容，数据都是【未加密】的，【安全性较差】。HTTPS 数据传输过程是【加密】的，【安全性较好】。
HTTP 和 HTTPS 使用的端口也不一样，前者是 80 端口，后者是 443 端口。
HTTPS 协议需要到数字认证机构（Certificate Authority, CA）申请证书，一般需要一定的费用。
HTTP 页面响应比 HTTPS 快，主要因为 HTTP 使用【 3 次握手建立连接】，客户端和服务器需要握手 3 次，而 HTTPS 除了 TCP 的 3 次握手，还需要经历一个【 SSL 协商过程】。

HTTP	HTTPs
明文传输，数据未加密，安全性较差	数据传输过程是加密的，安全性较好
不需要CA	需要到 CA（Certificate Authority，数字证书认证机构）申请证书，要钱
三次握手，简单，速度快	除了 TCP 的三次握手，还需要经历SSL 协商过程，速度慢，更耗资源

HTTPS 的加密方式

HTTPS 采用对称加密和非对称加密相结合的方式，首先使用 SSL/TLS 协议进行加密传输，为了弥补非对称加密的缺点，HTTPS 采用证书来进一步加强非对称加密的安全性，通过非对称加密，客户端和服务端协商好之后进行通信传输的对称密钥，后续的所有信息都通过该对称秘钥进行加密解密，完成整个 HTTPS 的流程。

客户端为什么信任第三方证书

假设中间人篡改了证书原文，由于他没有 CA 机构的私钥，所以无法得到此时加密后的签名，因此无法篡改签名。客户端浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书被中间人篡改，证书不可信，从而终止向服务器传输信息。

上述过程说明证书无法被篡改，我们考虑更严重的情况，例如中间人拿到了 CA 机构认证的证书，它想窃取网站 A 发送给客户端的信息，于是它成为中间人拦截到了 A 传给客户端的证书，然后将其替换为自己的证书。此时客户端浏览器收到的是被中间人掉包后的证书，但由于证书里包含了客户端请求的网站信息，因此客户端浏览器只需要把证书里的域名与自己请求的域名比对一下就知道证书有没有被掉包了。

如果你访问一个网站很慢，怎么排查和解决

网页打开速度慢的原因有很多，这里列举出一些较常出现的问题：

① 首先最直接的方法是查看本地网络是否正常，可以通过网络测速软件例如电脑管家等对电脑进行测速，若网速正常，我们查看网络带宽是否被占用，例如当你正在下载电影时并且没有限速，是会影响你打开网页的速度的，这种情况往往是处理器内存小导致的；

② 当网速测试正常时，我们对网站服务器速度进行排查，通过 ping 命令查看链接到服务器的时间和丢包等情况，一个速度好的机房，首先丢包率不能超过 1%，其次 ping 值要小，最后是 ping 值要稳定，如最大和最小差值过大说明路由不稳定。或者我们也可以查看同台服务器上其他网站的打开速度，看是否其他网站打开也慢。

③ 如果网页打开的速度时快时慢，甚至有时候打不开，有可能是空间不稳定的原因。当确定是该问题时，就要找你的空间商解决或换空间商了，如果购买空间的话，可选择购买购买双线空间或多线空间；如果是在有的地方打开速度快，有的地方打开速度慢，那应该是网络线路的问题。电信线路用户访问放在联通服务器的网站，联通线路用户访问放在电信服务器上的网站，相对来说打开速度肯定是比较慢。

④ 从网站本身找原因。网站的问题主要包括网站程序设计、网页设计结构和网页内容三个部分。

网站程序设计：当访问网页中有拖慢网站打开速度的代码，会影响网页的打开速度，例如网页中的统计代码，我们最好将其放在网站的末尾。因此我们需要查看网页程序的设计结构是否合理；
网页设计结构：如果是 table 布局的网站，查看是否嵌套次数太多，或是一个大表格分成多个表格这样的网页布局，此时我们可以采用 div 布局并配合 css 进行优化。
网页内容：查看网页中是否有许多尺寸大的图片或者尺寸大的 flash 存在，我们可以通过降低图片质量，减小图片尺寸，少用大型 flash 加以解决。此外，有的网页可能过多地引用了其他网站的内容，若某些被引用的网站访问速度慢，或者一些页面已经不存在了，打开的速度也会变慢。一种直接的解决方法是去除不必要的加载项。

其他协议

对于应用层来说，考察的重点集中在 HTTP 协议和 DNS 这两块，其他协议考察较少，我们仅加以了解即可。

FTP

FTP（File Transfer Protocol，文件传输协议）是用于在网络上进行文件传输的一套标准协议，使用客户/服务器模式，使用 TCP 数据报，提供交互式访问，双向传输。
TFTP（Trivial File Transfer Protocol，简单文件传输协议）一个小且易实现的文件传输协议，也使用客户/服务器方式，使用 UDP 数据报，只支持文件传输而不支持交互，没有列目录，不能对用户进行身份鉴定。

SMTP
SMTP（Simple Main 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 协议族的一部分。该协议能够支持网络管理系统，用以监测连接到网络上的设备是否有任何引起管理上关注的情况。

传输层

传输层的复用和分用

传输层(TCP/IP体系)通过端口号来区分不同的应用进程。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xQyzMFAr-1620458727951)(C:\Users\bj\AppData\Roaming\Typora\typora-user-images\image-20210506090830988.png)]

复用是指发送方不同的应用进程都可使用同一个传输层协议传送数据；
分用是指接收方的传输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程。

TCP协议是什么？

TCP协议是一个面向连接的，可靠的，基于字节流的全双工端对端通信协议。

NOTE：

TCP把应用层报文看成一连串的字节流，并将其进行编号，存储在发送缓存之中。

在进行发送时，会从缓存中提取一定数量的字节加上TCP首部进行发送。

面向连接的意味着数据发送方与数据接收方需要建立对话并维持该来连接。
可靠的意味着能保证数据安全准确的传输给对方。
基于字节流意味应用程序对于数据的发送和接收都是没有边界限制的。

补充：TCP基于字节流/UDP基于数据报的理解，TCP传输的send/recv函数，UDP的sendto/recvfrom函数。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8PT6x7HN-1620458727951)(C:\Users\bj\AppData\Roaming\Typora\typora-user-images\image-20210506094330751.png)]

简述TCP头部结构？

在这里插入图片描述
TCP头部与IP数据报头部一样均为20个字节,最大为60字节。

第一行

源端口号（16bit） + 目的端口号（16bit）：
端口号用于区分同一个IP地址下的不同应用程序。我们将 IP + Port 称为一个插口（Socket）。设立端口号的原因是同一个IP下可能运行了多个应用程序，如FTP（21），SMTP（25），SSH（22）等。

第二行

序列号（32bit）:
英文为seq，序列号的作用有两点，一是保证数据包的传输顺序，二是避免因网络延迟带来的网络混乱；客户端向服务器发送的序列号一般为ISN（initial sequence number） + 1；SYN和FIN会消耗掉一个序列号。

第三行

确认号（32bit）:
英文为ack，假设收到了ISN 为x的SYN报文，那么ack值就应该为x+1，代表已经收到了该报文。

第四行

头部长度（4bit）：最小为20字节（0101），最大为60字节（1111）
保留（6bit）
标志位（6bit）：
URG：紧急标志
ACK：确认标志，代表确认号是否有效
PSH：提示接收端应用程序应该立刻从TCP缓冲区读走数据，为后续接收数据腾出空间。
RST：复位报文段，要求重新建立连接
SYN：同步报文段，请求建立连接
FIN：结束报文段，通知对方本方将要关闭连接
窗口大小（16bit）：英文名 window size，也可以称为滑动窗口，是TCP流量控制的手段，用于告诉对方TCP接收缓冲区还能够接收多少字节的数据，这样对方可以控制发送数据的速度。窗口大小实质上对应了内核socket接收缓冲区的大小。

第五行

校验和（16bit）：使用CRC算法检验TCP报文段头部 + 数据部分是否有损坏，保证了TCP的可靠传输。
紧急指针（16bit）：紧急指针相对当前序列号的偏移，URG置位1时才有效，目前已弃用，不做过多了解。

选项：

是一个可变长的选项信息，最大为40个字节。

其中kind表示选项的类型，length指定选项的总长度，info是选项的具体信息

简述TCP三次握手与四次挥手？

三次握手

开始时客户端和服务器均处于 CLOSED 状态，在socket编程中，服务器 listen() 之后被动打开进入LISTEN状态，客户端 connection() 之后主动打开，之后进行三次握手：

第一次握手

客户端给服务器发送SYN报文，并指明想要连接的端口和客户端的ISN，客户端进入SYN-SENT状态。

TCP报文头部 SYN = 1 ， seq = x。
第二次握手

服务器收到了客户端的SYN报文之后，服务器对该包进行确认后结束 LISTEN 阶段,会发送自己的SYN-ACK报文作为应答，在报文中指明了自己的ISN；此时服务器处于SYN-RCVD 状态。

TCP报文头部 SYN = 1， ACK = 1，seq = y， ack = x + 1。
第三次握手

客户端接收到服务器的SYN之后，发送ACK报文作为应答发送后客户端进入 ESTABLISHED 状态，服务器收到ACK后也进入 ESTABLISHED 状态，双方开始数据交换。

TCP报文头部 ACK = 1， seq = x + 1，ack = y + 1。

这里写图片描述

TCP C/S模式

TCP三次握手会涉及到状态转换所以这里贴出TCP的状态转换图

这里写图片描述

四次挥手

开始时客户端和服务端都处于ESTABLISHED状态，假设客户端先发起关闭请求进行主动关闭，服务端接收到通知后，进行被动关闭。（四次挥手有可能是客户端发起的，也可能是服务器端发起的。）
在网络编程中，任意一方执行 close()操作，都会执行四次挥手。

第一次挥手

客户端向服务端发送FIN报文，同时指定自己的序列号，此时客户端处于 FIN-WAIT1 状态。

TCP报文头部信息：FIN = 1，seq = u。
第二次挥手

服务端接收到客户端的FIN报文后，发送ACK报文作为应答，服务端结束 ESTABLISHED 阶段，进入 CLOSE-WAIT 状态，客户端收到ACK后，结束 FIN-WAIT-1 阶段，进入 FIN-WAIT2状态，此时TCP处于半关闭状态，服务端仍然在向客户端发送数据。

TCP报文头部信息：ACK = 1，seq = v，ack = u + 1。
第三次挥手

服务端发送完数据之后，便做好了释放服务器端到客户端的连接准备，向客户端发送 FIN-ACK报文，此时服务端结束 CLOSE-WAIT 阶段，进入 LAST-ACK 阶段。

TCP报文头部信息：FIN = 1， ACK = 1，seq = w，ack = u + 1。
第四次挥手

客户端接收到服务端的FIN-ACK报文后，发送ACK报文给客户端，此时客户端结束 FIN-WAIT-2 阶段，进入 TIME-WAIT 阶段，需要等待 2MSL，之后进入CLOSED状态，服务端接收到ACK确认报文后，结束 LAST-ACK 阶段，进入 CLOSED 阶段。

TCP报文头部信息：ACK = 1，seq = u + 1， ack = w + 1。

在这里插入图片描述

补充：

SYN报文会消耗序列号，不能携带数据。
FIN报文会消耗序列号，不能携带数据。
ACK报文如果携带数据则会消耗序列号，如果不携带数据则不会消耗序列号。

如果三次握手的时候每次握手信息对方没有收到会怎么样

1、若第一次握手服务器未接收到客户端请求建立连接的数据包时，服务器不会进行任何相应的动作，而客户端由于在一段时间内没有收到服务器发来的确认报文，因此会等待一段时间后重新发送 SYN 同步报文，若仍然没有回应，则重复上述过程直到发送次数超过最大重传次数限制后，建立连接的系统调用connect()会返回 -1。(connect()函数，成功连接为0，失败为-1，函数默认会一直阻塞，直到三次握手成功或达到超时次数才返回)

2、若第二次握手客户端未接收到服务器回应的 ACK 报文时，客户端会采取第一次握手失败时的动作，这里不再重复，而服务器端此时将阻塞在 accept() 系统调用处等待 client端再次发送 ACK 报文。

3、若第三次握手服务器未接收到客户端发送过来的 ACK 报文，同样会采取类似于客户端的超时重传机制，若重传次数超过限制后仍然没有回应，则 accep() 系统调用返回 -1，服务器端连接建立失败。但此时客户端认为自己已经连接成功了，因此开始向服务器端发送数据，但是服务器端的 accept() 系统调用已返回，此时没有在监听状态。因此服务器端接收到来自客户端发送来的数据时会发送 RST 报文给客户端，消除客户端单方面建立连接的状态。

为什么要三次握手？只有两次握手可以吗？

为了实现可靠数据传输， TCP 协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知起始序列号，并确认对方已经收到了序列号起始值的必经步骤。
如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认。

TCP 协议为了实现可靠传输，通信双方需要判断自己已经发送的数据包是否都被接收方收到，如果没收到，就需要重发。为了实现这个需求，很自然地就会引出序号（sequence number） 和 确认号（acknowledgement number） 的使用。

三次握手才能保证双方的接收发送能力都是正常的，第三次握手有两点作用：

客户端的SYN报文因网络延时后滞后，此时客户端超时重传SYN报文并与服务器已经完成了数据的传输，随后第一次的SYN报文之后到达服务器，服务器误认为这是一次新的连接请求，于是发送SYN-ACK给客户端，并直接进入ESTABLISHED状态，但是客户端会直接忽略这一次SYN-ACK，导致死锁。
如果第二次握手的ACK信号丢失，服务器直接进入ESTABLISHED状态，而客户端没有收到ACK信号，还处于SYN-SENT阶段，则会形成死锁。

三次握手过程中可以携带数据吗？

第一次第二次握手不行，第三次握手可以；

假如第一次握手可以携带数据，那么如果有人要恶意攻击服务器，会在SYN报文中存入大量数据，并疯狂发送SYN报文，服务器将会因处理这些报文陷入瘫痪。

第三次握手返回ACK报文时，双方连接已经建立，自然可以携带数据。

为什么连接的时候是三次握手，关闭的时候却是四次挥手?(为什么挥手需要四次，三次挥手不行吗？）

挥手必须四次，因为四次挥手中，服务器收到FIN后，并不能立刻返回FIN-ACK，而是先发送ACK，也这是为什么挥手需要四次的原因，因为需要等到数据传输完成才行，再发送FIN-ACK，这两个不能合到一起发送，所以需要四次挥手来关闭连接。

第 2 次握手传回了 ACK，为什么还要传回 SYN

ACK 是为了告诉客户端发来的数据已经接收无误，而传回 SYN 是为了告诉客户端，服务端收到的消息确实是客户端发送的消息。

为什么要四次挥手？

释放 TCP 连接时之所以需要四次挥手，是因为 FIN 释放连接报文和 ACK 确认接收报文是分别在两次握手中传输的。当主动方在数据传送结束后发出连接释放的通知，由于被动方可能还有必要的数据要处理，所以会先返回 ACK 确认收到报文。当被动方也没有数据再发送的时候，则发出连接释放通知，对方确认后才完全关闭TCP连接。

CLOSE-WAIT 和 TIME-WAIT 的状态和意义

在服务器收到客户端关闭连接的请求并告诉客户端自己已经成功收到了该请求之后，服务器进入了 CLOSE-WAIT 状态，然而此时有可能服务端还有一些数据没有传输完成，因此不能立即关闭连接，而 CLOSE-WAIT 状态就是为了保证服务器在关闭连接之前将待发送的数据发送完成。

TIME-WAIT 发生在第四次挥手，当客户端向服务端发送 ACK 确认报文后进入该状态，若取消该状态，即客户端在收到服务端的 FIN 报文后立即关闭连接，此时服务端相应的端口并没有关闭，若客户端在相同的端口立即建立新的连接，则有可能接收到上一次连接中残留的数据包，可能会导致不可预料的异常出现。除此之外，假设客户端最后一次发送的 ACK 包在传输的时候丢失了，由于 TCP 协议的超时重传机制，服务端将重发 FIN 报文，若客户端并没有维持 TIME-WAIT 状态而直接关闭的话，当收到服务端重新发送的 FIN 包时，客户端就会用 RST 包来响应服务端，这将会使得对方认为是有错误发生，然而其实只是正常的关闭连接过程，并没有出现异常情况。

TIME_WAIT 状态会导致什么问题，怎么解决

我们考虑高并发短连接的业务场景，在高并发短连接的 TCP 服务器上，当服务器处理完请求后主动请求关闭连接，这样服务器上会有大量的连接处于 TIME_WAIT 状态，服务器维护每一个连接需要一个 socket，也就是每个连接会占用一个文件描述符，而文件描述符的使用是有上限的，如果持续高并发，会导致一些正常的连接失败。

解决方案：修改配置或设置 SO_REUSEADDR 套接字，使得服务器处于 TIME-WAIT 状态下的端口能够快速回收和重用。

有很多 TIME-WAIT 状态如何解决

服务器可以设置 SO_REUSEADDR 套接字选项来通知内核，如果端口被占用，但 TCP 连接位于 TIME_WAIT 状态时可以重用端口。如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时 SO_REUSEADDR 选项就可以避免 TIME-WAIT 状态。

也可以采用长连接的方式减少 TCP 的连接与断开，在长连接的业务中往往不需要考虑 TIME-WAIT 状态，但其实在长连接的业务中并发量一般不会太高。

有很多 CLOSE-WAIT 怎么解决

面试高频指数：★★★☆☆
首先检查是不是自己的代码问题（看是否服务端程序忘记关闭连接），如果是，则修改代码。
调整系统参数，包括句柄相关参数和 TCP/IP 的参数，一般一个 CLOSE_WAIT 会维持至少 2 个小时的时间，我们可以通过调整参数来缩短这个时间。

为什么客户端需要等待2MSL再关闭？

原因有两点：

2MSL=第四次挥手ACK消息最大存活时间（MSL) + 第三次挥手FIN_ACK报文的最大存活时间(MSL)；

保证客户端最后发送的ACK能够到达服务器（第四次挥手）
如果这个ACK报文丢失，服务器超时重传FIN-ACK，客户端在2MSL的时间内一定可以接收到这个超时重传的FIN-ACK，这样可以避免服务器没有收到最后的ACK而空等待。（）
防止旧连接中的报文影响新连接
客户端在发送最后一个ACK后，等待2MSL，这样该连接中的所有报文都已经在网络中消失，不会影响到下一个新的连接。

连接复位(RST)

有时候也会出现无法建立tcp连接或tcp连接异常终止的情况。一般来说，导致这种情况的原因一般有很多种，比如：

1.拒绝连接请求，比如：A想和B建立tcp连接，但是A的连接请求中使用了一个不存在的端口（比如：这个端口超出65535的范围或服务端未开启LISTEN状态），那么B就可以发送RST报文段拒绝这个请求。

2.异常终止连接，如:A和B的tcp连接出现了异常，然后B希望终止这条异常的连接，于是就可以发送一个RST报文段终止这个连接。

3.终止空闲的连接，如A和B之间的tcp连接已经很久没有传输数据了，空闲太长时间，可以发送RST报文段来终止这个连接。

对于RST报文段，另一端不需要发送任何响应，因为发送完RST报文后，这条tcp连接就关闭了，也就没有必要确认了，收到RST的一方将终止该连接，并通知应用层复位连接。

TCP中的计时器

重传计时器(Retransmission Timer)

目的：为了控制丢失的报文段或者丢弃的报文段。这段时间为对报文段的等待确认时间。
创建时间：在TCP发送报文段时，会创建对次特定报文段的重传计时器。
可能发生的两种情况：

1）在截止时间（通常为60秒）到之前，已经收到了对此特定报文段的确认，则撤销计时器；

2）在截止时间到了，但未收到对此特定报文段的确认，则重传报文段，并且将计时器复位。
重传时间：2*RTT（Round Trip Time，为往返时间）

持续计时器(Persistent Timer)

目的：主要解决零窗口大小通知可能导致的死锁问题。
死锁问题的产生：当接收端的窗口大小为0时，接收端向发送端发送一个零窗口报文段，发送端即停止向对端发送数据。此后，如果接收端缓存区有空间则会重新给发送端发送一个窗口大小，即窗口更新。但接收端发送的这个确认报文段有可能会丢失，而此时接收端不知道已经丢失并认为自己已经发送成功，则一直处于等待数据的状态；而发送端由于没有收到该确认报文段，就会一直等待对方发来新的窗口大小，这样一来，双方都处在等待对方的状态，这样就形成了一种死锁问题。如果没有应对措施，这种局面是不会被打破的。为了解决这种问题，TCP为每一个连接设置了坚持计时器。（注意：此时接收方不会重传，因为tcp规定对于没有携带数据的ACK确认报文段不会进行重传。）
工作原理：当发送端TCP收到接收端发来的零窗口通知时，就会启动坚持计时器。当计时器的期限到达时，发送端就会主动发送一个特殊的报文段告诉对方确认已经丢失。
– 【①这个特殊的报文段就称为探测报文段，探测报文段只有1个字节的大小，里边只有一个序号。
– 【②client在发送一个TCP ZeroWindowPro的探测报文时，同时也会诱导server发送一个探测报文的确认报文（也就是TCP ZeroWindowProACK报文），在这个确认报文中携带了当前的接收窗口大小。
– 【③若该探测报文段丢失，则将进行超时重传，即该报文也有超时重传计时器。
截止期的设置：设置为重传时间的值。但如果没有收到接收端的响应，则会发送另一个探测报文段，并将计时器的值加倍并复位，直到大于门限值（一般为60秒）。在此之后，发送端会每隔60秒发送一个探测报文段，直到窗口重新打开。

保活计时器(Keeplive Timer)

目的：主要是为了防止两个TCP连接出现长时间的空闲。当客户端与服务器端建立TCP连接后，很长时间内客户端都没有向服务器端发送数据，此时很有可能是客户端出现故障，而服务器端会一直处于等待状态。保活计时器就是解决这种问题而生的。
工作原理：每当服务器端收到客户端的数据时，都将保活计时器重新设置（通常设置为2小时）。过了2小时后，服务器端如果没有收到客户端的数据，会发送探测报文段给客户端，并且每隔75秒发送一个，当连续发送10次以后，仍没有收到对端的来信，则服务器端认为客户端出现故障，并会终止连接。

时间等待计时器(Time_Wait Timer)

目的：时间等待计时器是在连接终止期间使用的。当TCP关闭连接时并不是立即关闭的，在等待期间，连接还处于过渡状态。这样就可以使重复的FIN报文段在到达终点之后被丢弃。
时间设置：一般为报文段最大存活时间的2倍，即2MSL。

延迟应答计时器

延迟应答也被称为捎带 ACK，这个定时器是在延迟应答的时候使用的，为了提高网络传输的效率，当服务器接收到客户端的数据后，不是立即回 ACK 给客户端，而是等一段时间，这样如果服务端有数据需要发送给客户端的话，就可以把数据和 ACK 一起发送给客户端了

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 连接里面出现。

TCP的流量控制

流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制，接收方一般采用累计确认。
当接受缓冲区的剩余空间减小时，会改变窗口的大小来实现流量控制。

首先，接收方会对接收到的数据进行确认，然后计算出缓冲区剩余的空间大小得到rwnd（接收窗口），然后rwnd报文发送给发送方，进而调整滑动窗口的大小。但是在同一时刻，发送方的发送窗口大小并不总是和接收方的接收窗口一样大，因为网络传输需要经历一定的时间，存在滞后问题。另外，发送方还可能根据网络的拥塞情况适当的调整窗口的大小。发送窗口的上限值 = Min [rwnd, cwnd]。

Nagle算法

在TCP传输数据流中，存在两种类型的TCP报文段，一种包含成块数据（通常是满长度的，携带一个报文段最多容纳的字节数），另一种则包含交互数据（通常只有携带几个字节数据）。

对于成块数据的报文段，TCP采用正常的流程发送即可，因为资源利用率很高。而对于交互数据的报文段，资源利用率就显得很低，在网络环境不好的情况下容易加重网络负担。所以TCP必须对交互数据单独处理。

Nagle算法要求,当一个TCP连接中有在传数据(即那些已发送但还未经确认的数据),小的报文段(长度小于发送方最大报文段SMSS)就不能被发送,直到所有的在传数据都收到ACK。并且,在收到ACK后, TCP需要收集这些小数据,将其整合到一个报文段中发送。这种方法迫使TCP遵循停等( stop-and-Wait)规程——只有等接收到所有在传数据的ACK后才能继续发送。该算法的精妙之处在于它实现了自时钟(self-CIocking)控制: ACK返回越快,数据传输也越快。在启用Nagle算法的情况下,在任一时刻最多只有一个包在传。这样可以减少小包数目,但同时也增大了传输时延

虽然nagle算法可以减少网络中小分组的个数，但是对于那些需要实时预览的通讯程序而言，客户端可能需要不断发送更新数据并得到服务器的响应，这种情况下nagle算法会造成客户端明显的延迟，增大了传输时延，所以需要禁用nagle算法。

将套接字描述符设置TCP_NODELAY选项可以禁止nagle算法。

TCP滑动窗口机制引起的死锁问题以及糊涂窗口综合征

死锁问题：假定接收方收到报文，但不能继续接受新的报文，就发送一个窗口值为0的确认报文。此时，发送方停止发送，等待接收方发送一个非0窗口的确认报文启动发送，一段时间后，接收方发送一个非0窗口确认报文，但是该报文在传输过程中丢失了，从而导致发送方不能发送，接收方不能接受，于是出现死锁。（采用持续计时器可以解决该问题）

糊涂窗口综合征（SWS）

TCP连接的两端都可能导致糊涂窗口综合征的出现:接收端的通告窗口（rwnd）较小(没有等到窗口变大

才通告)，或者发送端发送的数据段较小(没有等待将其他数据组合成一个更大的报文段)。

SWS解决办法

1.对于发送端

采用Nagle算法控制，全长报文（成块报文）可以发送；数据段长度>=rwnd的一半时，可以发送。

2.对于接收端

对于接收端来说，不应通告小的窗口值。在窗口可增至一个全长的报文段（即接收端MSS）或者接收端缓存空间的一半（取两者中较小者）之前，不能通告比当前窗口（可能为0）更大的窗口值。注意到可能有两种情况会用到该规则:当应用程序处理接收到的数据后使得可用缓存增大，以及TCP接收端需要强制返回对窗口探测的响应。

什么是半连接队列？什么是全连接队列？

半连接状态

半连接状态也就是服务器在进行第二次握手之后进入SYN-REVD的状态，并且这些连接由半连接队列存放。

全连接状态

全连接状态也就是完成了三次握手的连接，全连接队列将存放这些连接。

ISN是什么？是固定的吗？

ISN是TCP三次握手中为了建立连接而使用的一个初始序列号，ISN随时间而变化（每4ms加1），因此每一个连接都有不同的ISN。

ISN不固定有两个好处：

如果ISN固定，上一次连接的报文因网络延迟在这一次连接中到达，并恰好两次的seq相同，那么就会发生网络混乱。
固定ISN容易遭受到黑客攻击，黑客能得知服务器的ISN，能在第三次握手正确的返回ACK报文，与服务器建立连接。

SYN攻击是什么？(泛洪攻击是什么？)

黑客伪造大量不存在的IP地址，并不断向Server发送SYN请求，由于IP地址不存在，Server会不断发送SYN-ACK报文直至超时，这些伪造的SYN报文将导致半连接队列满，导致正常的SYN请求因无法加入半连接队列而被丢弃，这样会造成服务器瘫痪。

常见的防御SYN攻击的方法有：

1.过滤网关防护：如设置SYN代理，让代理为服务器处理SYN请求，如果收到了客户端的ACK包那么就向服务器完成三次握手。

2.增大半连接队列容量

3.缩短超时时间与减少重传次数

4.SYNcookies技术

如果已经建立了连接，但是客户端突然出现故障了怎么办?

服务端会有一个Keep-Alive心跳包机制，也就是定期内会通过发送数据包检测客户端是否正常运行，那么就认为客户端已经出现故障，服务器自动断开。

为什么会发生TCP粘包拆包？如何处理？

TCP粘包发生的原理是TCP传输是基于字节流的，发送端发送数据与接收端接收数据并没有边界，没有边界导致所有的数据粘合在了一起，也就发生了TCP粘包。
在socket编程中，假设发送方执行send操作x次，都只是将x次的数据发送到发送缓冲区中，真正发送到对端是由TCP协议来完成；而接受方执行recv操作y次之后将数据读取出来，并不是发送一次就对应着接受一次。

TCP粘包发生的原因

发送方写入的数据小于套接字缓冲区大小，由于 TCP 默认使用 Nagle 算法，只有当收到一个确认后，才将分组发送给对端，当发送方收集了多个较小的分组，就会一起发送给对端，这将会发生粘包。
发送方发送的数据太快，接收方处理数据的速度赶不上发送端的速度，将发生粘包；

TCP拆包发生的原因

待发送的数据部分大于MSS（最大报文长度），需要进行拆分；
待发送的数据部分大于发送缓冲区剩余空间大小，需要进行拆分。

TCP粘包拆包的处理方法
通常使用 自定义私有协议 的方式来解决，协议可以按照以下方式设计：

发送端发送数据时添加包头部，在消息的头部添加消息长度字段，再发送数据部分；接收端先接受到包头部，确定了数据部分的大小之后再读取数据部分即可进行拆包。
发送端发送数据时将数据包封装为固定长度，不够的用0补齐；接收端每一次接受固定长度的包即可进行拆包。
设置消息边界，一般使用 ‘\n’ 作为边界。

TCP协议如何保证可靠传输？

简答

数据分块：应用数据被分割成 TCP 认为最适合发送的数据块。
序列号和确认应答：TCP 给发送的每一个包进行编号，在传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答，即发送 ACK 报文，这个 ACK 报文当中带有对应的确认序列号，告诉发送方成功接收了哪些数据以及下一次的数据从哪里开始发。除此之外，接收方可以根据序列号对数据包进行排序，把有序数据传送给应用层，并丢弃重复的数据。
校验和： TCP 将保持它首部和数据部分的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到报文段的检验和有差错，TCP 将丢弃这个报文段并且不确认收到此报文段。
流量控制： TCP 连接的双方都有一个固定大小的缓冲空间，发送方发送的数据量不能超过接收端缓冲区的大小。当接收方来不及处理发送方的数据，会提示发送方降低发送的速率，防止产生丢包。TCP 通过滑动窗口协议来支持流量控制机制。
拥塞控制：当网络某个节点发生拥塞时，减少数据的发送。
ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
超时重传：当 TCP 发出一个报文段后，它启动一个定时器，等待目的端确认收到这个报文段。如果超过某个时间还没有收到确认，将重发这个报文段。

细答

连接管理

通过三次握手与四次挥手保证能稳定的建立连接与结束连接。

序列号+确认号

保证对数据包的有序发送与有序接收。

校验和

保证TCP报文段的头部与数据部分准确传输，若检验和有差错，接收端将丢弃次报文并不返回ACK报文。

超时重传机制

发送方在发送一次数据后就开启一个定时器，在一定时间内如果没有得到发送数据包的 ACK 报文，那么就重新发送数据，在达到一定次数还没有成功的话就放弃重传并发送一个复位信号。其中超时时间的计算是超时的核心，而定时时间的确定往往需要进行适当的权衡，因为当定时时间过长会造成网络利用率不高，定时太短会造成多次重传，使得网络阻塞。在 TCP 连接过程中，会参考当前的网络状况从而找到一个合适的超时时间。

发送端将缓冲区的数据发送后，并不会立刻删除缓冲区中的数据，而是收到ACK后才会删除缓冲区的数据，在等待RTO后也没有收到ACK后，将会重发数据。

注：RTO（Retransmisson Time Out）是超时重传时间，超时重传时间一般略大于加权平均往返时间RTTs，又称平滑的往返时间。当发生超时重传时，报文段每重传一次，就把超时重传时间RTO增大一些，典型的做法是将新RTO的值取为旧RTO值的2倍。

ARQ（Auto Repeat Request）协议

ARQ协议是数据链路层和传输层的错误纠正协议之一，分为停止等待ARQ（TCP采用了该协议），回退n帧ARQ，选择重传ARQ。

停止等待ARQ协议：发送一个报文段之后，必须收到该报文段的ACK之后，才发送下一个报文段，否则重传该报文。在已发送但未确认的报文被确认之前, 发送方的滑动窗口将不会滑动。
回退n帧ARQ协议：接收窗口为1，需要从出现错误的帧开始，将之后的全部帧进行重传。
选择重传ARQ：接收窗口大于1，只需要重传错误的帧。

设置滑动窗口进行流量控制

滑动窗口是以字节为单位，在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，以此限制发送方向网络注入报文的速率。TCP发送端与接收端都有内核socket缓冲区。

拥塞控制

当网络出现拥塞时，应该控制发送方的发送速率，因为如果发送方没有收到ACK，会不断超时重传从而让网络更为拥挤。流量控制与拥塞控制本质上都是为了降低发送方的发送速率。

拥塞控制的四个算法：慢开始，拥塞避免，快重传与快恢复。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QWYQssCf-1620458727957)(C:\Users\bj\AppData\Roaming\Typora\typora-user-images\image-20210506111528839.png)]

慢开始算法：慢开始算法的思路是，如果刚开始在不了解网络状况的情况下，就把大量数据传输到网络中，可能会直接引起网络阻塞；那么应该从小到大增大阻塞窗口，将cwnd初始值设为1，每经过一个轮次，cwnd值增大一倍（指数增长）。慢开始指的是开始阶段向网络中注入的报文段较少。
拥塞避免算法：拥塞避免算法的思路是让cwnd缓慢增大，每经过一次RTT（往返时间）增加1。一般当拥塞窗口的值大于门限值时使用拥塞避免算法。当出现超时重传时，判断网络可能出现了拥塞，于是将慢开始门限值降为发生拥塞时cwnd大小的一半，将cwnd值降为1并重新使用慢开始算法。
快重传算法：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ijmhoVXr-1620458727959)(C:\Users\bj\AppData\Roaming\Typora\typora-user-images\image-20210506113135787.png)]

快重传算法也就是当发送方一连收到连续3个重复的ACK确认，那么相应报文段立刻重传，而不是等待超时重传。
快恢复算法：在收到连续三次重复的ACK确认后，立刻执行快重传并进行快恢复；将 慢开始门限值 与 拥塞窗口值（cwnd）均变为原来拥塞窗口值的一半，并执行拥塞避免算法，将cwdn大小进行线性增大。

如果接收方滑动窗口满了，发送方会怎么做

基于 TCP 流量控制中的滑动窗口协议，我们知道接收方返回给发送方的 ACK 包中会包含自己的接收窗口大小，若接收窗口已满，此时接收方返回给发送方的接收窗口大小为 0，此时发送方会等待接收方发送的窗口大小直到变为非 0 为止，然而，接收方回应的 ACK 包是存在丢失的可能的，为了防止双方一直等待而出现死锁情况，此时就需要坚持计时器来辅助发送方周期性地向接收方查询，以便发现窗口是否变大【持续计时器参考问题】，当发现窗口大小变为非零时，发送方便继续发送数据。

TCP 最大连接数限制

Client 最大 TCP 连接数
client 在每次发起 TCP 连接请求时，如果自己并不指定端口的话，系统会随机选择一个本地端口（local port），该端口是独占的，不能和其他 TCP 连接共享。TCP 端口的数据类型是 unsigned short，因此本地端口个数最大只有 65536，除了端口 0不能使用外，其他端口在空闲时都可以正常使用，这样可用端口最多有 65535 个。
Server最大 TCP 连接数
server 通常固定在某个本地端口上监听，等待 client 的连接请求。不考虑地址重用（Unix 的 SO_REUSEADDR 选项）的情况下，即使 server 端有多个 IP，本地监听端口也是独占的，因此 server 端 TCP 连接 4 元组中只有客户端的 IP 地址和端口号是可变的，因此最大 TCP 连接为客户端 IP 数 × 客户端 port 数，对 IPV4，在不考虑 IP 地址分类的情况下，最大 TCP 连接数约为 2 的 32 次方（IP 数）× 2 的 16 次方（port 数），也就是 server 端单机最大 TCP 连接数约为 2 的 48 次方。

然而上面给出的是只是理论上的单机最大连接数，在实际环境中，受到明文规定（一些 IP 地址和端口具有特殊含义，没有对外开放）、机器资源、操作系统等的限制，特别是 sever 端，其最大并发 TCP 连接数远不能达到理论上限。对 server 端，通过增加内存、修改最大文件描述符个数等参数，单机最大并发 TCP 连接数超过 10 万是没问题的。

SYN FLOOD 是什么

SYN Flood 是种典型的 DoS（拒绝服务）攻击，其目的是通过消耗服务器所有可用资源使服务器无法用于处理合法请求。通过重复发送初始连接请求（SYN）数据包，攻击者能够压倒目标服务器上的所有可用端口，导致目标设备根本不响应合法请求。

为什么服务端易受到 SYN 攻击

在 TCP 建立连接的过程中，因为服务端不确定自己发给客户端的 SYN-ACK 消息或客户端反馈的 ACK 消息是否会丢在半路，所以会给每个待完成的半开连接状态设一个定时器，如果超过时间还没有收到客户端的 ACK 消息，则重新发送一次 SYN-ACK 消息给客户端，直到重试超过一定次数时才会放弃。

服务端为了维持半开连接状态，需要分配内核资源维护半开连接。当攻击者伪造海量的虚假 IP 向服务端发送 SYN 包时，就形成了 SYN FLOOD 攻击。攻击者故意不响应 ACK 消息，导致服务端被大量注定不能完成的半开连接占据，直到资源耗尽，停止响应正常的连接请求。

解决方法：

直接的方法是提高 TCP 端口容量的同时减少半开连接的资源占用时间，然而该方法只是稍稍提高了防御能力；
部署能够辨别恶意 IP 的路由器，将伪造 IP 地址的发送方发送的 SYN 消息过滤掉，该方案作用一般不是太大；

上述两种方法虽然在一定程度上能够提高服务器的防御能力，但是没有从根本上解决服务器资源消耗殆尽的问题，而以下几种方法的出发点都是在发送方发送确认回复后才开始分配传输资源，从而避免服务器资源消耗殆尽。

SYN Cache：该方法首先构造一个全局 Hash Table，用来缓存系统当前所有的半开连接信息。在 Hash Table 中的每个桶的容量大小是有限制的，当桶满时，会主动丢掉早来的信息。当服务端收到一个 SYN 消息后，会通过一个映射函数生成一个相应的 Key 值，使得当前半连接信息存入相应的桶中。当收到客户端正确的确认报文后，服务端才开始分配传输资源块，并将相应的半开连接信息从表中删除。和服务器传输资源相比，维护表的开销要小得多。
SYN Cookies：该方案原理和 HTTP Cookies 技术类似，服务端通过特定的算法将半开连接信息编码成序列号或者时间戳，用作服务端给客户端的消息编号，随 SYN-ACK 消息一同返回给连接发起方，这样在连接建立完成前服务端不保存任何信息，直到发送方发送 ACK 确认报文并且服务端成功验证编码信息后，服务端才开始分配传输资源。若请求方是攻击者，则不会向服务端会 ACK 消息，由于未成功建立连接，因此服务端并没有花费任何额外的开销。

然而该方案也存在一些缺点，由于服务端并不保存半开连接状态，因此也就丧失了超时重传的能力，这在一定程度上降低了正常用户的连接成功率。此外，客户端发送给服务端的确认报文存在传输丢失的可能，当 ACK 确认报文丢失时，服务端和客户端会对连接的成功与否产生歧义，此时就需要上层应用采取相应的策略进行处理了。

SYN Proxy：在客户端和服务器之间部署一个代理服务器，类似于防火墙的作用。通过代理服务器与客户端进行建立连接的过程，之后代理服务器充当客户端将成功建立连接的客户端信息发送给服务器。这种方法基本不消耗服务器的资源，但是建立连接的时间变长了（总共需要 6 次握手）。

并发服务器客户端主动关闭连接和服务端主动关闭连接的区别

以下是针对 TCP 服务来说的：

服务端主动关闭连接

在高并发场景下，当服务端主动关闭连接时，此时服务器上就会有大量的连接处于 TIME-WAIT 状态
客户端主动关闭连接
当客户端主动关闭连接时，我们并不需要关心 TIME-WAIT 状态过多造成的问题，但是需要关注服务端保持大量的 CLOSE-WAIT 状态时会产生的问题【见问题 10 的解决方法】

无论是客户端还是服务器主动关闭连接，从本质上来说，在高并发场景下主要关心的就是服务端的资源占用问题，而这也是采用 TCP 传输协议必须要面对的问题，其问题解决的出发点也是如何处理好服务质量和资源消耗之间的关系。

简述UDP协议？UDP的头部结构？

应用进程数据（报文）+UDP首部得到用户数据报，我们将用户数据报协议（User Datagram Protocol）称为UDP，它是一种 无连接，不可靠，基于数据报 的协议。

NOTE：

UDP不对应用层报文进行拆分或合并，保留报文边界。

无连接：数据发送方与数据接收方不需要建立对话并维持该连接。
不可靠：不能保证数据安全准确的传输给对方，提供“尽力而为”的交付服务。
基于数据报：与基于字节流不同，数据的发送与接收是有边界的。

UDP数据报头部结构如下：
在这里插入图片描述
UDP头部长为固定的8字节；

第一行
源端口号（16bit） + 目的端口号（16bit）
第二行

UDP总长度（16bit）：此处的总长度为UDP 头部+数据部分的长度，数据部分的长度受数据链路层MTU的限制，通常最大为1472字节（1500-20字节IP头部-8字节UDP头部）。
UDP检验和（16bit）：当检验到错误时，UDP不做纠正，而是直接将数据丢弃。

往下：
数据部分（最大1472字节）

TCP/UDP协议的区别

这个问题属于一个发散性，综合性的问题，相当于让面试者详细的解释TCP协议与UDP协议。

TCP是有连接，可靠的，基于字节流的协议；UDP是无连接，不可靠，基于(应用报文)数据报的协议。（详细说出连接，可靠，基于字节流，基于数据报的意思，见上面的回答）
TCP头部结构复杂，网络开销和时延都较大；UDP头部结构较为简单，网络开销和时延都较小。（画出TCP头部与UDP头部，并解释，见上面的回答）
TCP能通过建立连接，确认序号，滑动窗口，超时重传，拥塞控制，检验和等方式让数据包安全准确的传到对端；UDP则是提供不可靠的交付。（详细解释TCP可靠的原因，见上面的回答）
TCP一般用于文件传输，收发邮件，远程登录，HTTP等，UDP一般用于即时通信，比如语音，视频，直播，DNS等。

UDP支持单播，多播以及广播，TCP仅支持单播。

类型	是否面向连接	传输可靠性	传输形式	传输效率	所需资源	应用场景	首部字节
TCP	是	可靠	字节流	慢	多	文件传输、邮件传输	20~60
UDP	否	不可靠	数据报文段	快	少	即时通讯、域名转换	8个字节

UDP 为什么是不可靠的？bind 和 connect 对于 UDP 的作用是什么

UDP 只有一个 socket 接收缓冲区，没有 socket 发送缓冲区，即只要有数据就发，不管对方是否可以正确接收。而在对方的 socket 接收缓冲区满了之后，新来的数据报无法进入到 socket 接受缓冲区，此数据报就会被丢弃，因此 UDP 不能保证数据能够到达目的地，此外，UDP 也没有流量控制和重传机制，故UDP的数据传输是不可靠的。

和 TCP 建立连接时采用三次握手不同，UDP 中调用 connect 只是把对端的 IP 和端口号记录下来，并且 UDP 可多多次调用 connect 来指定一个新的 IP 和端口号，或者断开旧的 IP 和端口号（通过设置 connect 函数的第二个参数）。和普通的 UDP 相比，调用 connect 的 UDP 会提升效率，并且在高并发服务中会增加系统稳定性。

当 UDP 的发送端调用 bind 函数时，就会将这个套接字指定一个端口，若不调用 bind 函数，系统内核会随机分配一个端口给该套接字。当手动绑定时，能够避免内核来执行这一操作，从而在一定程度上提高性能。

网络层

简述IP协议？IP协议的头部结构？

IP协议是一种无连接，不可靠，尽力交付的点对点通信协议。IP协议将不同的帧转换为统一的IP数据报的格式，使得不同技术网络，不同操作系统下的计算机也能够实现相互连通。

无连接：数据发送方与数据接收方不需要建立对话并维持该连接。
不可靠：不能保证数据安全准确的传输给对方，提供“尽力而为”的交付服务。
点对点：在两个网络节点之间交换数据。

IP 协议主要有以下几个作用：

寻址和路由：在IP 数据包中会携带源 IP 地址和目的 IP 地址来标识该数据包的源主机和目的主机。IP 数据报在传输过程中，每个中间节点（IP 网关、路由器）只根据网络地址进行转发，如果中间节点是路由器，则路由器会根据路由表选择合适的路径。IP 协议根据路由选择协议提供的路由信息对 IP 数据报进行转发，直至抵达目的主机。
分段与重组：IP 数据包在传输过程中可能会经过不同的网络，在不同的网络中数据包的最大长度限制是不同的，IP 协议通过给每个 IP 数据包分配一个标识符以及分段与组装的相关信息，使得数据包在不同的网络中能够传输，被分段后的 IP 数据报可以独立地在网络中进行转发，在到达目的主机后由目的主机完成重组工作，恢复出原来的 IP 数据包。

IP数据报的头部结构如下：
在这里插入图片描述

IP数据报头部最小为20个字节，最大为60个字节。为了方便叙述，将头部结构分为5行，每一行4字节（32位）。

第一行

版本号（4bit）：一般是IPv4，目前IPv6仍然处于草案阶段。
头长度（4bit）：一般头部长度为20个字节（0101），最大为60个字节（1111）。每一位代表4个字节，同时头部的长度也必须是4字节的整数倍（可以用充填字段充填）。
服务类型（8bit）：为不同的数据包定义不同的服务质量，可以设置优先级，最小延时，最大吞吐量，最高可用性等服务，如ssh和telnet需要最小延时的服务，而文件传授ftp需要最大吞吐量的服务，另外一些紧急的数据包需要设置最高的优先级。
总长度（16bit）：IP头部与数据段的总长度，每一位代表1字节，所以最大长度理论上为2^16-1 = 65535字节。当IP数据报总长度超过MTU时，就必须进行分片。

第二行

标识（16bit）：当IP数据报长度超过MTU时，必须进行分片。标识字段的值就被复制到所有分片的数据报中，相同的标识字段就能够进行组装成原来的IP数据报。
标志（3bit）：MF（more fragment），DF（don’t fragment）
片偏移（13bit）：较大的IP数据报在分片后，该分片在原数据报中的位置。

通过IP数据包的分片，可以让IP分组在不同技术的网络，不同的操作系统上进行传输。

第三行

TTL（8bit）：功能是对路由器进行跳数限制，是防止无法交付的数据报在网络中兜圈子。每经过一个路由器，TTL减1，当TTL==0 时则丢弃该数据报；最大值可设置为255，设置为1则表示该数据报只能在本局域网中传送。
上层协议标识（8bit）：区分IP协议上的上层协议，如ICMP为1，TCP为6，UDP为7。用来保证接收方知道该用哪一种协议来处理该数据报。
头部校验和（16bit）：重新检验数据报的首部，但不包括数据部分。因为对数据的校验工作由传输层协议来完成，网络层协议只负责数据包在两个网络点之间进行传输。

第四行

源地址（32bit）

第五行

目的地址（32bit）

可变部分（0~40字节）

简述IP地址的组成？

IP地址可以在因特网中唯一的标识某一台计算机或设备。

IP地址是一个四字节32位的数，常采用 点分十进制 的方式展现。编址方式：网络号+ 主机号，同一个物理网络上的所有主机都属于同一个网络ID，每一个主机（如工作站，服务器，路由器等）都有一个主机ID。

IP地址的组成：

在这里插入图片描述

A类地址

1个字节的网络号，3个字节的主机号，用于大规模网络；
网络ID最高位必须是0，可拥有的网络数是2⁷-2个，主机数是2²⁴-2个；
默认子网掩码是255.0.0.0，私网是10.0.0.0 ~ 10.255.255.255。

注：网络号-2的原因是0一般不用，127作为回环地址；主机号-2的原因是主机号全为0表示当前主机地址，主机号全为1表示广播地址。

B类地址

2个字节的网络号，2个字节的主机号，用于中型规模网络；
网络ID最高位必须为10，可拥有的网络数是2¹⁴个，主机数是2¹⁶-2个;
默认子网掩码是255.255.0.0，私网是172.16.0.0 ~ 172.31.255.255。

C类地址

3个字节的网络号，1个字节的主机号，用于小型网络；
网络ID最高位必须是110，可拥有的网络号是2²¹个，主机号是2⁸-2个；
默认子网掩码是255.255.255.0，私网是192.168.0.0~192.168.255.255。

D类地址

D类地址称为广播地址也可以称为多播，组播地址；
网络ID开头必须为1110，范围为223.0.0.0~239.255.255.255；
每个地址对应着一个组，发往某一组播地址的数据将被该组中所有成员接收。

D类地址不能够分配给主机。

E类地址

E类地址作为保留地址之后使用。

特殊地址

特殊地址也就是专用的地址，不能够分配给主机使用：

0.0.0.0
并不是一个真实的地址，对应着当前网络所有的IP地址。
回环地址
以127开头的地址称为回环地址，给回环地址发送的IP数据报都会被主机接收，外部设备也无法通过回环地址访问该主机；回环地址通常用来测试某台机器的网络设备是否正常。
主机地址全为0
对应着当前的网络地址
主机地址每个字节都为1
对应着该网络的广播地址

0.0.0.0 与 127.0.0.1 与 localhost的区别?

127.0.0.1
实际上从127.0.0.1~127.255.255.254都属于回环地址，都能够ping通，只是我们默认在回环地址中使用127.0.0.1进行测试。
localhost
实际上经过DNS域名解析后的localhost就是127.0.0.1，就像www.baidu.com（域名，或者说别名）对应着它自己的IP地址一样。
0.0.0.0
并不是一个真实的地址，对应着当前网络所有的IP地址。

举例说明：
PC1 和 PC2 在同一个局域网中，PC1的地址是172.21.0.7

PC1作为server监听172.21.0.7，PC1中的client只能够连接上172.21.0.7，PC2的client只能连接上172.21.0.7
PC1作为server监听127.0.0.1，PC1中的client只能连接上127.0.0.1，PC2中的client都连接不上。
PC1作为server监听0.0.0.0，PC1中的client两个都能连接上，PC2中的client可以连接上172.21.0.7

NAT协议的作用？（公网与私网的区别？）

NAT协议的作用实现公网IP地址与私网IP地址之间的相互映射转换，使得一个公网IP地址下能够有多个私网IP。
作用：

解决了IPv4地址枯竭的问题；
主机的安全性得到了保障，因为就算暴露了私网IP也没有关系。

我们的家庭网络，以及寝室都是采用的这种NAT协议。

举例：

我寝室里面的主机（公网IP为125.1.2.3，私网IP为10.1.0.2）向Web服务器（公网IP为162.105.129.12）请求服务。由内网到外网时，将源IP地址从10.1.0.2改为125.1.2.3，从外网到内网时，将目的IP地址从125.1.2.3改为10.1.0.2，由NAT路由器进行路由表映射操作完成。
NAT路由表如下：

在这里插入图片描述

NAT（Network Address Translation），即网络地址转换，它是一种把内部私有网络地址翻译成公有网络 IP 地址的技术。该技术不仅能解决 IP 地址不足的问题，而且还能隐藏和保护网络内部主机，从而避免来自外部网络的攻击。

NAT 的实现方式主要有三种：

静态转换：内部私有 IP 地址和公有 IP 地址是一对一的关系，并且不会发生改变。通过静态转换，可以实现外部网络对内部网络特定设备的访问，这种方式原理简单，但当某一共有 IP 地址被占用时，跟这个 IP 绑定的内部主机将无法访问 Internet。
动态转换：采用动态转换的方式时，私有 IP 地址每次转化成的公有 IP 地址是不唯一的。当私有 IP 地址被授权访问 Internet 时会被随机转换成一个合法的公有 IP 地址。当 ISP 通过的合法 IP 地址数量略少于网络内部计算机数量时，可以采用这种方式。
端口多路复用：该方式将外出数据包的源端口进行端口转换，通过端口多路复用的方式，实现内部网络所有主机共享一个合法的外部 IP 地址进行 Internet 访问，从而最大限度地节约 IP 地址资源。同时，该方案可以隐藏内部网络中的主机，从而有效避免来自 Internet 的攻击。

ARP协议是什么？

ARP协议（Address Resolution Protocol）的作用是实现从IP地址到MAC地址的映射。

主机发送信息时将包含 目标IP地址 的 ARP请求 在 局域网 进行广播，并根据返回的消息确定 目标IP地址 的 MAC地址，以 <IP，MAC> 形式存入 ARP缓存表。

举例：ARP协议工作过程
主机A IP:192.168.0.1 MAC: 0A-11-22-33-44-01
主机B IP:192.168.0.2 MAC: 0A-11-22-33-44-02

A在路由表中找到主机B的IP地址是192.168.0.2。
A在ARP缓存表中查找B的IP映射MAC地址，发现没有找到，于是在局域网内进行广播，发出的帧包含A的IP地址以及MAC地址。
除B以外的主机接收到帧后，发现目标地址与自己的地址并不匹配，于是将帧丢弃；主机B接收到帧后，将主机A的<IP，MAC>信息存入自己的ARP缓存表，并发送回应消息。
A接收到消息，将B的<IP，MAC>信息存入ARP缓存表。
A将IP数据报装帧，发送给B。

注意：ARP请求只能在局域网中进行，且ARP协议并不会验明其真实性就记入ARP缓存，所以发送的信息可能会到达错误的主机，形成ARP欺骗。

ARP 地址解析协议的原理和地址解析过程

ARP（Address Resolution Protocol）是地址解析协议的缩写，该协议提供根据 IP 地址获取物理地址的功能，它工作在第二层，是一个数据链路层协议，其在本层和物理层进行联系，同时向上层提供服务。当通过以太网发送 IP 数据包时，需要先封装 32 位的 IP 地址和 48位 MAC 地址。在局域网中两台主机进行通信时需要依靠各自的物理地址进行标识，但由于发送方只知道目标 IP 地址，不知道其 MAC 地址，因此需要使用地址解析协议。 ARP 协议的解析过程如下：

① 首先，每个主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址之间的对应关系；

② 当源主机要发送数据时，首先检查 ARP 列表中是否有 IP 地址对应的目的主机 MAC 地址，如果存在，则可以直接发送数据，否则就向同一子网的所有主机发送 ARP 数据包。该数据包包括的内容有源主机的 IP 地址和 MAC 地址，以及目的主机的 IP 地址。

③ 当本网络中的所有主机收到该 ARP 数据包时，首先检查数据包中的目的主机IP 地址是否是自己的 IP 地址，如果不是，则忽略该数据包，如果是，则首先从数据包中取出源主机的 IP 和 MAC 地址写入到 ARP 列表中，如果已经存在，则覆盖，然后将自己的 MAC 地址写入 ARP 响应包中，告诉源主机自己是它想要找的 MAC 地址。

④ 源主机收到 ARP 响应包后。将目的主机的 IP 和 MAC 地址写入 ARP 列表，并利用此信息发送数据。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。

域名和 IP 的关系，一个 IP 可以对应多个域名吗

IP 在同一个网络中是唯一的，用来标识每一个网络上的设备，其相当于一个人的身份证号；域名在同一个网络中也是唯一的，就像一个人的名字，绰号。假如你有多个不同的绰号，你的朋友可以用其中任何一个绰号叫你，但你的身份证号码却是唯一的。通常，一个域名只对应一个 IP 地址，是一对一的关系；而一个 IP 却可以对应多个域名，是一对多的关系。一个 IP 可以对应多个域名，一个域名其实也可以通过DNS对应多个 IP 地址。

IPV4 地址不够如何解决

DHCP：动态主机配置协议。动态分配 IP 地址，只给接入网络的设备分配IP地址，因此同一个 MAC 地址的设备，每次接入互联网时，得到的IP地址不一定是相同的，该协议使得空闲的 IP 地址可以得到充分利用。
CIDR：无类别域间路由。CIDR 消除了传统的 A 类、B 类、C 类地址以及划分子网的概念，因而更加有效的分配 IPv4 的地址空间，但无法从根本上解决地址耗尽问题。
NAT：网络地址转换协议。我们知道属于不同局域网的主机可以使用相同的 IP 地址，从而一定程度上缓解了 IP 资源枯竭的问题。然而主机在局域网中使用的 IP 地址是不能在公网中使用的，当局域网主机想要与公网进行通信时， NAT 方法可以将该主机 IP 地址转换成全球 IP 地址。该协议能够有效解决 IP 地址不足的问题。
IPv6 ：作为接替 IPv4 的下一代互联网协议，其可以实现 2 的 128 次方个地址，而这个数量级，即使是给地球上每一颗沙子都分配一个IP地址，该协议能够从根本上解决 IPv4 地址不够用的问题。

路由器的分组转发流程

① 从 IP 数据包中提取出目的主机的 IP 地址，找到其所在的网络；

② 判断目的 IP 地址所在的网络是否与本路由器直接相连，如果是，则不需要经过其它路由器直接交付，否则执行 ③；

③ 检查路由表中是否有目的 IP 地址的特定主机路由。如果有，则按照路由表传送到下一跳路由器中，否则执行 ④；

④ 逐条检查路由表，若找到匹配路由，则按照路由表转发到下一跳路由器中，否则执行步骤 ⑤；

⑤ 若路由表中设置有默认路由，则按照默认路由转发到默认路由器中，否则执行步骤 ⑥；

⑥ 无法找到合适路由，向源主机报错。

路由器和交换机的区别

交换机：交换机用于局域网的数据转发，利用主机的物理地址（MAC 地址）确定数据转发的目的地址，它工作在数据链路层。交换机会转发广播数据。
路由器：路由器用于连接局域网和外网，路由器通过数据包中的目的 IP 地址识别不同的网络从而确定数据转发的目的地址，网络号是唯一的。路由器根据路由选择协议和路由表信息从而确定数据的转发路径，直到到达目的网络，它工作于网络层。路由器不会转发广播数据。（一般路由器同时也具有交换机功能，LAN口就是作为交换机的端口来使用，WAN是用于连接外网的端口）

ICMP 协议概念/作用

ICMP（Internet Control Message Protocol）是因特网控制报文协议，主要是实现 IP 协议中未实现的部分功能，是一种网络层协议。该协议并不传输数据，只传输控制信息来辅助网络层通信。其主要的功能是验证网络是否畅通（确认接收方是否成功接收到 IP 数据包）以及辅助 IP 协议实现尽可能可靠传输（若发生 IP 丢包，ICMP 会通知发送方 IP 数据包被丢弃的原因，之后发送方会进行相应的处理）。

TTL 是什么？有什么作用

TTL 是指生存时间，简单来说，它表示了数据包在网络中的时间。每经过一个路由器后 TTL 就减一，这样 TTL 最终会减为 0 ，当 TTL 为 0 时，则将数据包丢弃。通过设置 TTL 可以避免这两个路由器之间形成环导致数据包在环路上死转的情况，由于有了 TTL ，当 TTL 为 0 时，数据包就会被抛弃。

运输层协议和网络层协议的区别

网络层协议负责提供主机间的逻辑通信；运输层协议负责提供进程间的逻辑通信。

两台电脑连起来后 ping 不通，你觉得可能存在哪些问题？

首先看网络是否连接正常，检查网卡驱动是否正确安装。
局域网设置问题，检查 IP 地址是否设置正确。
看是否被防火墙阻拦（有些设置中防火墙会对 ICMP 报文进行过滤），如果是的话，尝试关闭防火墙。
看是否被第三方软件拦截。
两台设备间的网络延迟是否过大（例如路由设置不合理），导致 ICMP 报文无法在规定的时间内收到。

PING命令中用到的协议

1、DNS，作用：把域名转换成为网络可以识别的ip地址

2、ARP，作用：根据IP地址获取MAC物理地址

3、ICMP，作用：TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息（如网络通不通、主机是否可达、路由是否可用等网络本身的消息）。

一个ip绑定多个域名，怎么识别

一个ip绑定多个域名可以采用两种方法：

通过端口来区分不同的站点
通过ServerName区分不同的域名

数据链路层

MAC 地址和 IP 地址分别有什么作用

MAC 地址是数据链路层和物理层使用的地址，是写在网卡上的物理地址。MAC 地址用来定义网络设备的位置。
IP 地址是网络层和以上各层使用的地址，是一种逻辑地址。IP 地址用来区别网络上的计算机。

为什么有了 MAC 地址还需要 IP 地址

如果我们只使用 MAC 地址进行寻址的话，我们需要路由器记住每个 MAC 地址属于哪一个子网，不然每一次路由器收到数据包时都要满世界寻找目的 MAC 地址。而我们知道 MAC 地址的长度为 48 位，也就是说最多总共有 2 的 48 次方个 MAC 地址，这就意味着每个路由器需要 256 T 的内存，这显然是不现实的。

和 MAC 地址不同，IP 地址是和地域相关的，在一个子网中的设备，我们给其分配的 IP 地址前缀都是一样的，这样路由器就能根据 IP 地址的前缀知道这个设备属于哪个子网，剩下的寻址就交给子网内部实现，从而大大减少了路由器所需要的内存。

私网地址和公网地址之间进行转换：同一个局域网内的两个私网地址，经过转换之后外面看到的一样吗

当采用静态或者动态转换时，由于一个私网 IP 地址对应一个公网地址，因此经过转换之后的公网 IP 地址是不同的；而采用端口复用方式的话，在一个子网中的所有地址都采用一个公网地址，但是使用的端口是不同的。

以太网中的 CSMA/CD 协议

CSMA/CD 为载波侦听多路访问/冲突检测，是像以太网这种广播网络采用的一种机制，我们知道在以太网中多台主机在同一个信道中进行数据传输，CSMA/CD 很好的解决了共享信道通信中出现的问题，它的工作原理主要包括两个部分：

载波监听：当使用 CSMA/CD 协议时，总线上的各个节点都在监听信道上是否有信号在传输，如果有的话，表明信道处于忙碌状态，继续保持监听，直到信道空闲为止。如果发现信道是空闲的，就立即发送数据。
冲突检测：当两个或两个以上节点同时监听到信道空闲，便开始发送数据，此时就会发生碰撞（数据的传输延迟也可能引发碰撞）。当两个帧发生冲突时，数据帧就会破坏而失去了继续传输的意义。在数据的发送过程中，以太网是一直在监听信道的，当检测到当前信道冲突，就立即停止这次传输，避免造成网络资源浪费，同时向信道发送一个「冲突」信号，确保其它节点也发现该冲突。之后采用一种二进制退避策略让待发送数据的节点随机退避一段时间之后重新。

数据链路层上的三个基本问题

封装成帧：将网络层传下来的分组前后分别添加首部和尾部，这样就构成了帧。首部和尾部的一个重要作用是帧定界，也携带了一些必要的控制信息，对于每种数据链路层协议都规定了帧的数据部分的最大长度。
透明传输：帧使用首部和尾部进行定界，如果帧的数据部分含有和首部和尾部相同的内容，那么帧的开始和结束的位置就会判断错，因此需要在数据部分中出现有歧义的内容前边插入转义字符，如果数据部分出现转义字符，则在该转义字符前再加一个转义字符。在接收端进行处理之后可以还原出原始数据。这个过程透明传输的内容是转义字符，用户察觉不到转义字符的存在。
差错检测：目前数据链路层广泛使用循环冗余检验（CRC）来检查数据传输过程中是否产生比特差错。

PPP 协议

互联网用户通常需要连接到某个 ISP 之后才能接入到互联网，PPP（点对点）协议是用户计算机和 ISP 进行通信时所使用的数据链路层协议。点对点协议为点对点连接上传输多协议数据包提供了一个标准方法。该协议设计的目的主要是用来通过拨号或专线方式建立点对点连接发送数据，使其成为各种主机、网桥和路由器之间简单连接的一种解决方案。

PPP 协议具有以下特点：

PPP 协议具有动态分配 IP 地址的能力，其允许在连接时刻协商 IP 地址。
PPP 支持多种网络协议，例如 TCP/IP、NETBEUI 等。
PPP 具有差错检测能力，但不具备纠错能力，所以 PPP 是不可靠传输协议。
无重传的机制，网络开销小，速度快。
PPP 具有身份验证的功能。

为什么 PPP 协议不使用序号和确认机制

IETF 在设计因特网体系结构时把其中最复杂的部分放在 TCP 协议中，而网际协议 IP 则相对比较简单，它提供的是不可靠的数据包服务，在这种情况下，数据链路层没有必要提供比 IP 协议更多的功能。若使用能够实现可靠传输的数据链路层协议，则开销就要增大，这在数据链路层出现差错概率不大时是得不偿失的。
即使数据链路层实现了可靠传输，但其也不能保证网络层的传输也是可靠的，当数据帧在路由器中从数据链路层上升到网络层后，仍有可能因为网络层拥塞而被丢弃。
PPP 协议在帧格式中有帧检验序列，对每一个收到的帧，PPP 都会进行差错检测，若发现差错，则丢弃该帧。

物理层

主机之间的通信方式

单工通信：也叫单向通信，发送方和接收方是固定的，消息只能单向传输。例如采集气象数据、家庭电费，网费等数据收集系统，或者打印机等应用主要采用单工通信。
半双工通信：也叫双向交替通信，通信双方都可以发送消息，但同一时刻同一信道只允许单方向发送数据。例如传统的对讲机使用的就是半双工通信。
全双工通信：也叫双向同时通信，全双工通信允许通信双方同时在两个方向是传输，其要求通信双方都具有独立的发送和接收数据的能力。例如平时我们打电话，自己说话的同时也能听到对面的声音。

通道复用技术

频分复用（FDM，Frequency Division Multiplexing）
频分复用将传输信道的总带宽按频率划分为若干个子频带或子信道，每个子信道传输一路信号。用户分到一定的频带后，在数据传输的过程中自始至终地占用这个频带。由于每个用户所分到的频带不同，使得传输信道在同一时刻能够支持不同用户进行数据传输，从而实现复用。除了传统意义上的 FDM 外，目前正交频分复用（OFDM）已在高速通信系统中得到广泛应用。

时分复用（TDM，Time Division Multiplexing）
顾名思义，时分复用将信道传输信息的时间划分为若干个时间片，每一个时分复用的用户在每一个 TDM 帧中占用固定时隙进行数据传输。用户所分配到的时隙是固定的，所以时分复用有时也叫做同步时分复用。这种分配方式能够便于调节控制，但是也存在缺点，当某个信道空闲时，其他繁忙的信道无法占用该空闲信道，因此会降低信道利用率。

波分复用（WDM，Wavelength Division Multiplexing）
在光通信领域通常按照波长而不是频率来命名，因为光的频率和波长具有单一对应关系，因此 WDM 本质上也是 FDM，光通信系统中，通常由光来运载信号进行传输，WDM 是在一条光纤上传输多个波长光信号，其将 1 根光纤看做多条「虚拟」光纤，每条「虚拟」光纤工作在不同的波长上，从而极大地提高了光纤的传输容量。

码分复用（CDM，Code Division Multiplexing）
码分复用是靠不同的编码来区分各路原始信号的一种复用方式，不同的用户使用相互正交的码字携带信息。由于码组相互正交，因此接收方能够有效区分不同的用户数据，从而实现每一个用户可以在同样的时间在同样的频带进行数据传输，频谱资源利用率高。其主要和各种多址接入技术相结合从而产生各种接入技术，包括无线和优先接入。

网络安全

安全攻击有哪些

网络安全攻击主要分为被动攻击和主动攻击两类：

被动攻击：攻击者窃听和监听数据传输，从而获取到传输的数据信息，被动攻击主要有两种形式：消息内容泄露攻击和流量分析攻击。由于攻击者并没有修改数据，使得这种攻击类型是很难被检测到的。
主动攻击：攻击者修改传输的数据流或者故意添加错误的数据流，例如假冒用户身份从而得到一些权限，进行权限攻击，除此之外，还有重放、改写和拒绝服务等主动攻击的方式。

DDoS 有哪些，如何防范

DDoS 为分布式拒绝服务攻击，是指处于不同位置的多个攻击者同时向一个或数个目标发动攻击，或者一个攻击者控制了不同位置上的多台机器并利用这些机器对受害者同时实施攻击。和单一的 DoS 攻击相比，DDoS 是借助数百台或者数千台已被入侵并添加了攻击进程的主机一起发起网络攻击。

DDoS 攻击主要有两种形式：流量攻击和资源耗尽攻击。前者主要针对网络带宽，攻击者和已受害主机同时发起大量攻击导致网络带宽被阻塞，从而淹没合法的网络数据包；后者主要针对服务器进行攻击，大量的攻击包会使得服务器资源耗尽或者 CPU 被内核应用程序占满从而无法提供网络服务。

常见的 DDos 攻击主要有：TCP 洪泛攻击（SYN Flood）、放射性攻击（DrDos）、CC 攻击（HTTP Flood）等。

针对 DDoS 中的流量攻击，最直接的方法是增加带宽，理论上只要带宽大于攻击流量就可以了，但是这种方法成本非常高。在有充足网络带宽的前提下，我们应尽量提升路由器、网卡、交换机等硬件设施的配置。

针对资源耗尽攻击，我们可以升级主机服务器硬件，在网络带宽得到保证的前提下，使得服务器能有效对抗海量的 SYN 攻击包。我们也可以安装专业的抗 DDoS 防火墙，从而对抗 SYN Flood等流量型攻击。此外，负载均衡，CDN 等技术都能够有效对抗 DDoS 攻击。

RSA 和 AES 算法有什么区别

RSA
采用非对称加密的方式，采用公钥进行加密，私钥解密的形式。其私钥长度一般较长，除此之外，由于需要大数的乘幂求模等运算，其运算速度较慢，不适合大量数据文件加密。

AES
采用对称加密的方式，其密钥长度最长只有 256 个比特，加密和解密速度较快，易于硬件实现。由于是对称加密，通信双方在进行数据传输前需要获知加密密钥。

基于上述两种算法的特点，一般使用 RSA 传输密钥给对方，之后使用 AES 进行加密通信。

对称加密和非对称的区别，非对称加密有哪些

加密和解密的过程不同：对称加密和解密过程使用同一个密钥；非对称加密中加密和解密采用公钥和私钥两个密钥，一般使用公钥进行加密，使用私钥进行解密。
加密和解密的速度不同：对称加密和解密速度较快，当数据量比较大时适合使用；非对称加密和解密时间较长，速度相对较慢，适合少量数据传输的场景。
传输的安全性不同：采用对称加密方式进行通信时，收发双方在数据传送前需要协定好密钥，而这个密钥还有可能被第三方窃听到的，一旦密钥泄漏，之后的通信就完全暴漏给攻击者了；非对称加密采用公钥加密和私钥解密的方式，其中私钥是基于不同的算法生成的随机数，公钥可以通过私钥通过一定的算法推导得出，并且私钥到公钥的推导过程是不可逆的，也就是说公钥无法反推导出私钥，即使攻击者窃听到传输的公钥，也无法正确解出数据，所以安全性较高。

常见的非对称加密算法主要有：RSA、Elgamal、背包算法、Rabin、D-H 算法等等。

ARP 攻击

在 ARP 的解析过程中，局域网上的任何一台主机如果接收到一个 ARP 应答报文，并不会去检测这个报文的真实性，而是直接记入自己的 ARP 缓存表中。并且这个 ARP 表是可以被更改的，当表中的某一列长时间不适使用，就会被删除。ARP 攻击就是利用了这一点，攻击者疯狂发送 ARP 报文，其源 MAC 地址为攻击者的 MAC 地址，而源 IP 地址为被攻击者的 IP 地址。通过不断发送这些伪造的 ARP 报文，让网络内部的所有主机和网关的 ARP 表中被攻击者的 IP 地址所对应的 MAC 地址为攻击者的 MAC 地址。这样所有发送给被攻击者的信息都会发送到攻击者的主机上，从而产生 ARP 欺骗。通常可以把 ARP 欺骗分为以下几种：

洪泛攻击
攻击者恶意向局域网中的网关、路由器和交换机等发送大量 ARP 报文，设备的 CPU 忙于处理 ARP 协议，而导致难以响应正常的服务请求。其表现通常为：网络中断或者网速很慢。
欺骗主机
这种攻击方式也叫仿冒网关攻击。攻击者通过 ARP 欺骗使得网络内部被攻击主机发送给网关的信息实际上都发送给了攻击者，主机更新的 ARP 表中对应的 MAC 地址为攻击者的 MAC。当用户主机向网关发送重要信息使，该攻击方式使得用户的数据存在被窃取的风险。
欺骗网关
该攻击方式和欺骗主机的攻击方式类似，不过这种攻击的欺骗对象是局域网的网关，当局域网中的主机向网关发送数据时，网关会把数据发送给攻击者，这样攻击者就会源源不断地获得局域网中用户的信息。该攻击方式同样会造成用户数据外泄。
中间人攻击
攻击者同时欺骗网关和主机，局域网的网关和主机发送的数据最后都会到达攻击者这边。这样，网关和用户的数据就会泄露。
IP 地址冲突
攻击者对局域网中的主机进行扫描，然后根据物理主机的 MAC 地址进行攻击，导致局域网内的主机产生 IP 冲突，使得用户的网络无法正常使用。

AES 的过程

AES（Advanced Encryption Standard）即密码学的高级加密标准，也叫做 Rijndeal 加密法，是为最为常见的一种对称加密算法，和传统的对称加密算法大致的流程类似，在发送端需要采用加密算法对明文进行加密，在接收端需要采用与加密算法相同的算法进行解密，不同的是， AES 采用分组加密的方式，将明文分成一组一组的，每组长度相等，每次加密一组数据，直到加密完整个明文。在 AES 标准中，分组长度固定为 128 位，即每个分组为 16 个字节（每个字节有 8 位）。而密钥的长度可以是 128 位，192 位或者 256 位。并且密钥的长度不同，推荐加密的轮数也不同。

我们以 128 位密钥为例（加密轮次为 10），已知明文首先需要分组，每一组大小为16个字节并形成 4 × 4 的状态矩阵（矩阵中的每一个元素代表一个字节）。类似地，128 位密钥同样用 4 × 4 的字节矩阵表示，矩阵中的每一列称为 1 个 32 位的比特字。通过密钥编排函数该密钥矩阵被扩展成一个由 44 个字组成的序列，该序列的前四个字是原始密钥，用于 AES 的初始密钥加过程，后面 40 个字分为 10 组，每组 4 个字分别用于 10 轮加密运算中的轮密钥加。在每轮加密过程中主要包括四个步骤：

① 字节代换：AES 的字节代换其实是一个简易的查表操作，在 AES 中定义了一个 S-box 和一个逆 S-box，我们可以将其简单地理解为两个映射表，在做字节代换时，状态矩阵中的每一个元素（字节）的高四位作为行值，低四位作为列值，取出 S-box 或者逆 S-box 中对应的行或者列作为输出。

② 行位移：顾名思义，就是对状态矩阵的每一行进行位移操作，其中状态矩阵的第 0 行左移 0 位，第 1 行左移 1 位，以此类推。

③ 列混合：列混合变换是通过矩阵相乘来实现的，经唯一后的状态矩阵与固定的矩阵相乘，从而得到混淆后的状态矩阵。其中矩阵相乘中涉及到的加法等价于两个字节的异或运算，而乘法相对复杂一些，对于状态矩阵中的每一个 8 位二进制数来说，首先将其与 00000010 相乘，其等效为将 8 位二进制数左移一位，若原二进制数的最高位是 1 的话再将左移后的数与 00011011 进行异或运算。

④ 轮密相加：在开始时我们提到，128 位密钥通过密钥编排函数被扩展成 44 个字组成的序列，其中前 4 个字用于加密过程开始时对原始明文矩阵进行异或运算，而后 40 个字中每四个一组在每一轮中与状态矩阵进行异或运算（共计 10 轮）。

上述过程即为 AES 加密算法的主要流程，在我们的例子中，上述过程需要经过 10 轮迭代。而 AES 的解密过程的各个步骤和加密过程是一样的，只是用逆变换取代原来的变换。