计算机网络相关知识点

1 OSI七层模型

OSI七层模型由应用层、表示层、会话层、传输层、网络层、数据链路层、物理层组成。

传输层数据被称为段（Segments）
网络层数据被称为包（Packages）
数据链路层时数据被称为帧（Frames）
物理层时数据被称为比特流（Bits）

1.1 物理层

底层数据传输，如网线；网卡标准

1.2 数据链路层

定义数据的基本格式，如何传输，如何标识；如网卡MAC地址

1.3 网络层

定义IP编址，定义路由功能；如不同设备的数据转发

1.4 传输层

端到端传输数据的基本功能；如 TCP、UDP

1.5 会话层

控制应用程序之间会话能力；如不同软件数据分发给不同软件

1.6 表示层

数据格式标识，基本压缩加密功能

1.7 应用层

各种应用软件，包括 Web 应用

2 TCP/IP四层模型

TCP/IP四层模型由应用层、传输层、网络层、网络接口层组成。可以简单地将TCP/IP四层模型与OSI七层模型对应起来。

2.1 应用层

• 主要提供终端设备上的应用进程(进程是主机中正在运行的程序)之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输。应用层交互的数据单元称为报文。
• 应用层协议定义了网络通信规则，对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如支持 Web 应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等
  

2.2 传输层

• 任务是负责向终端设备的应用进程之间的通信提供通用的数据传输服务。应用进程利用该服务传输应用层报文。所谓通用的，是指并不针对某个特定的网络应用，而是多种应用可以使用同一个传输层服务。由于一台主机可以同时运行多个进程，因此运输层有复用和分用的功能。
• 传输层主要使用以下两种协议
  • 传输控制协议TCP(Transmisson Control Protocol)：提供面向连接的，可靠的数据传输服务，其数据传输的单位是报文段(segment)。
  • 用户数据协议UDP(User Datagram Protocol)：提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性），其数据传输的单位是用户数据报。
    

2.3 网络层

• 在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。
• 发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP体系结构中，由于网络层使用IP协议，因此分组也叫IP数据报，简称数据报。

运输层的“用户数据报”不等于网络层的“IP 数据报”，此外，无论是哪一层的数据单元，都可以笼统的用"分组"表示

• 网络层使用的协议是无连接的网际协议（Intert Prococol）和许多路由选择协议，因此网络层也叫做网际层或IP 层
  

2.4 网络接口层

可以把网络接口层看作是数据链路层和物理层的合体

• 数据链路层：简称为链路层（ 两台主机之间的数据传输，总是在一段一段的链路上传送的）。数据链路层的作用是将网络层传下来的IP数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
  • 在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始到哪个比特结束，这样数据链路层在收到一个帧后，就可从中提取出数据部分，上交到网络层。
  • 控制信息还能使接收端能够检测到所收到的帧中有无差错。若发现有差错，数据链路层就简单丢弃这个出了差错的帧，以免其继续在网络传输下去而浪费资源。若需改正差错(即,数据链路层不仅要检错,还要纠错)， 可以采用可靠的数据传输协议来纠正出现的差错。但是这种方法会使数据链路层的协议复杂些。
• 物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异
  

3 HTTP

3.1 怎么理解HTTP协议

HTTP协议即超文本传输协议(超文本，是网络上的包括文本在内的各式各样的消息)。

当我们在浏览器地址栏上输入URL后，浏览器会通过DNS解析到对应IP上，浏览器根据这个IP将IP地址与Web服务器进行通信，这个通信的协议就是HTTP协议，说白了，HTTP协议就是规定了客户端和服务器端之间通讯的一种规范和格式，只有两者都遵循这个协议，两者在接受和响应请求的时候才能达到一致。

HTTP是一个无状态（stateless）协议，也就是说服务器端不维护任何有关客户端过去所发请求的消息。这其实是一种懒政，有状态协议会更加复杂，需要维护状态（历史信息）。如果客户或服务器失效，会导致产生的状态不一致，而解决这种不一致的代价更高。

3.2 HTTP请求和响应包括哪些内容

3.2.1 HTTP请求

浏览器向服务器请求某个web资源，称浏览器向服务器发送了一个http请求（客户端 --> 服务器）

3.2.1.1 请求格式

1. 请求首行
2. 请求头
3. 空行
4. 请求体（请求正文）

3.2.1.2 请求方式

• POST：没有请求体，但空行是存在的，附带的参数有限制，数据容量不能超过1k
• GET：存在请求体，可以在请求的实体内容中向服务器发送数据，传送的数据量无限制
• 在浏览器地址栏中发送请求，以及点击超链接都是GET请求
• 提交表单既可以使用GET，也可以使用POST方式，推荐使用POST方式，查询数据的时候推荐使用GET方式

3.2.1.3 请求头

• Accept-Charset:ISO-8859-1：客户端告诉服务器，所支持的字符集格式
• Accept-Encoding:gzip,deflate,br：客户端告诉服务器，所支持的压缩格式
• Accept-Language:en-us,zh-cn：客户端告诉服务器，它的语言环境
• Connection:close/Keep-Alive：客户端告诉服务器，请求完后是断开链接或保持链接
• Cookie：客户端告诉服务器，所带来的的cookie
• Host:xxxxxx ：客户端告诉服务器，想访问哪台主机
• User-Agent：表示浏览器内核
• Referer：xxxxx：客户端告诉服务器，客户机从哪个页面来的，防盗链前发出请求的地址，例如在浏览器地址栏直接访问服务器，那么没有这个请求头。如果是在www.baidu.com页面上点击链接访问的服务器，那么这个头的值为www.baidu.com
• Content-Type：如果是POST请求，会有这个头，默认值为application/x-www-form-urlencoded，表示请求体内容使用 url 编码
  

3.2.2 HTTP响应

代表服务器向客户端回送数据

3.2.2.1 响应格式

1. 响应首行：
   协议及版本 状态码 状态码说明，例如：HTTP/1.1 200 OK

2. 响应头

3. 空行

4. 响应体（响应正文）

3.2.2.2 常见状态码

状态码	解释
200	请求成功
302	请求重定向
304	请求资源没有改变
404	请求资源不存在，客户端错误
500	服务器内部错误

eg.状态码304的相关头信息

• Last-Modified：响应头，表示当前资源的最后修改时间；
• If-Modified-Since：请求头，表示缓存的资源最后修改时间；

1. 客户端首次访问服务器的静态资源index.html，服务器会把index.html响应给客户端，而且还会添加一个名为Last-Modified的响应头，它说明了当前index.html的最后修改时间
2. 客户端收到响应后，会把index.html缓存在客户端上，而且还会把Last-Modified缓存起来。
3. 客户端第二次请求index.html时，会添加名为If-Modified-Since的请求头，它的值一般是上次服务器的响应头Last-Modified。服务器将获取到的客户端保存的最后修改时间，与当前资源的最后修改时间进行比较，如果相同，说明index.html没有改动过，那么服务器不会发送index.html，而是返回响应状态码304，即通知客户端资源没有改变，你可以使用自己的缓存；如果不同，说明index.html被修改过，那么服务器返回响应状态码200，并发送全新的index.html。

3.2.2.3 响应头

• Content-Type：响应正文的类型。image/jpeg表示响应正文为jpg图片，text/html;charset=utf-8表示响应正文为html，并且编码为utf-8编码。浏览器会通过这一信息来显示响应数据。

• Content-Length：响应正文的长度

• Set-Cookie：服务器端告诉客户端要保存Cookie

• Date：响应时间，可能会有8小时的误差，因为中国的时区问题

• Refresh: 3;url=http://www.xxxx：自动刷新，3秒后浏览器自动重定向到页面
  通知浏览器不要缓存页面的响应头：

• Expires:-1

• Cache-Control: no-cache

• Pragma: no-cache
  

3.3 HTTP1.0 vs HTTP1.1

3.3.1 响应状态码

HTTP/1.0仅定义了16种状态码。HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如，100 (Continue)——在请求大资源前的预热请求，206 (Partial Content)——范围请求的标识码，409 (Conflict)——请求与当前资源的规定冲突，410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址。

3.3.2 缓存处理

缓存技术通过避免用户与源服务器的频繁交互，节约了大量的网络带宽，降低了用户接收信息的延迟

• HTTP/1.0
  服务器端使用Expires响应头来标志一个响应体，在Expires标志时间内的请求，都会获得该响应体缓存。具体通过Last-Modified标签和If-Modified-Since标签实现。

• HTTP/1.1
  HTTP/1.1的缓存机制在HTTP/1.0的基础上，大大增加了灵活性和扩展性。

基本工作原理和HTTP/1.0一致，但是增加了更多细致的特性。其中，请求头中最常见的特性就是Cache-Control。

3.3.3 连接方式

• HTTP/1.0默认使用短连接。即，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS 文件等），每遇到这样一个 Web资源，浏览器就会重新建立一个TCP连接，这样导致有大量的“握手报文”和“挥手报文”占用了带宽。
• 为了解决HTTP/1.0存在的资源浪费问题，HTTP/1.1优化为默认长连接模式 。采用长连接模式的请求报文会通知服务端：“我向你请求连接，并且连接成功建立后，请不要关闭”。因此，该TCP连接将持续打开，为后续的客户端-服务端的数据交互服务。也就是说在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
• 如果TCP连接一直保持的话也是对资源的浪费，因此，一些服务器软件（如 Apache）会在超时时间之内没有新的请求到达时，将TCP连接关闭。
• HTTP/1.0提供了长连接选项，即在请求头中加入Connection: Keep-alive。同样的，在HTTP/1.1中，如果不希望使用长连接选项，也可以在请求头中加入Connection:close，这样会通知服务器端：“我不需要长连接，连接成功后即可关闭”。
• HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
• 实现长连接需要客户端和服务端都支持长连接。

3.3.4 Host头处理

域名系统（DNS）允许多个主机名绑定到同一个IP地址上即在一台物理服务器上可以存在多个虚拟主机，但是HTTP/1.0认为每台主机都绑定一个唯一的IP地址。

因此，HTTP/1.1在请求头中加入了Host字段，且若请求头中没有Host字段会报错（400 Bad Request）。

eg.假设我们有一个资源URL是http://example1.org/home.html，HTTP/1.0的请求报文中，请求的是GET /home.html HTTP/1.0。即，请求报文中的URL并没有传递主机名（hostname）。通过这样的报文，服务器端不能确定客户端要请求的真正网址。 而加入Host字段的报文头部是:

GET /home.html HTTP/1.1
Host: example1.org

这样服务器端可以确定客户端要请求的真正网址。

3.3.5 带宽优化

• 范围请求
  HTTP/1.1引入了范围请求机制，以避免带宽的浪费。当客户端想请求一个文件的一部分，或者需要继续下载一个已经下载一部分但被终止的文件时，HTTP/1.1可以在请求中加入Range头部，以请求（并只能请求字节型数据）数据的一部分。服务器端可以忽略Range头部，也可以返回若干Range响应。

若一个响应包含部分数据，将带有206(Partial Content)状态码。该状态码的意义在于避免了HTTP/1.0代理缓存将该响应认为是一个完整的数据响应，从而保证了将该响应作为一个请求的响应缓存。

在范围响应中，Content-Range头部标志指示出了该数据块的偏移量和数据块的长度。

• 状态码100
  HTTP/1.1中新增了状态码100。该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码100可以作为指示请求是否会被正常响应，过程如下图：

HTTP/1.0中，没有100状态码，要想触发这一机制，可以发送一个Expect头部，其中包含一个100-continue的值。

• 压缩
  数据的压缩可以大幅优化带宽的利用。

HTTP/1.0提供的数据压缩选项不多，不支持压缩细节的选择，也无法区分端到端（end-to-end）压缩和逐跳（hop-by-hop）压缩。

HTTP/1.1对内容编码（content-codings）和传输编码（transfer-codings）做了区分。内容编码总是端到端的，传输编码总是逐跳的。

HTTP/1.0包含了Content-Encoding头部，对消息进行端到端内容编码。HTTP/1.1加入了Transfer-Encoding头部，对消息进行逐跳传输编码；加入了Accept-Encoding头部，客户端用来指示他能处理什么样的内容编码。

3.3.6 总结

• 连接方式:HTTP/1.0为短连接，HTTP/1.1支持长连接。
• 状态响应码: HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如，100——在请求大资源前的预热请求，206——范围请求的标识码，409——请求与当前资源的规定冲突，410——资源已被永久转移，而且没有任何已知的转发地址。
• 缓存处理:HTTP/1.0主要使用header里的If-Modified-Since,Expires作为缓存判断的标准，HTTP/1.1则引入了更多的缓存控制策略，例如Entity tag，If-Unmodified-Since, If-Match,If-None-Match等更多可供选择的缓存头。
• 带宽优化及网络连接的使用:HTTP/1.0存在浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来，并且不支持断点续传功能，HTTP/1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样方便了开发者自由的选择以便于充分利用带宽和连接。
• Host头处理: HTTP/1.1在请求头中加入了Host字段。

3.4 HTTP vs HTTPS

3.4.1 HTTP协议通信过程

HTTP是应用层协议，以TCP（传输层）为底层协议，默认端口为80。通信过程如下：

1. 服务器在80端口等待客户的请求
2. 浏览器发起到服务器的TCP连接（创建套接字Socket）
3. 服务器接收来自浏览器的TCP连接
4. 浏览器（HTTP客户端）与Web服务器（HTTP服务器）交换HTTP信息
5. 关闭TCP连接

3.4.2 HTTP协议优点

扩展性强、速度快、跨平台支持性好。

3.4.3 HTTPS协议

HTTPS协议是HTTP的加强安全版本。HTTPS基于HTTP，也以TCP作为底层协议，并额外使用SSL/TLS协议用作加密和安全认证。默认端口号是 443。

HTTPS协议中，SSL通道通常使用基于密钥的加密算法，密钥长度通常是 40比特或128比特。

• SSL/TLS协议
  SSL指安全套接字协议（Secure Sockets Layer）。TLS基于SSL，但由于习惯叫法，通常把HTTPS中的核心加密协议混成为SSL/TLS。

SSL/TLS的核心要素是非对称加密。非对称加密采用两个密钥(一个公钥，一个私钥)。在通信时，私钥仅由解密者保存，公钥由任何一个想与解密者通信的发送者（加密者）所知。

非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS实际对消息的加密使用的是对称加密。

对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。
网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。

3.4.4 HTTPS协议优点

保密性好、信任度高。

3.4.5 总结

• 端口号：HTTP默认是80，HTTPS 默认是443。
• URL 前缀：HTTP的URL前缀是http://，HTTPS的URL前缀是https://。
• 安全性和资源消耗：HTTP协议基于TCP，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS基于SSL/TLS，而SSL/TLS又运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以HTTP安全性没有HTTPS高，但是HTTPS比HTTP耗费更多服务器资源。

3.5 从浏览器输入URL到显示页面发生了什么

上图有一个错误，注意是OSPF不是 OPSF。 OSPF（Open Shortest Path First）开放最短路径优先协议, 是由Internet工程任务组开发的路由选择协议

1. DNS解析：通过输入的URL获取对应的IP
2. TCP连接：与服务器建立TCP连接
3. 发送HTTP请求：浏览器向Web服务器发送一个HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析渲染页面
6. 连接结束

4.常见的面试题

4.1 应用层有哪些常见的协议

HTTP:超文本传输协议

超文本传输协议主要是为Web浏览器与Web服务器之间的通信而设计的。使用浏览器浏览网页时，网页就是通过HTTP请求进行加载的，发送HTTP请求之前要先建立TCP连接也就是要经历3次握手。

目前使用的HTTP协议大部分为1.1版本。1.1默认开启Keep-Alive，这样建立的连接可以在多次请求中被复用。

HTTP协议是”无状态”的协议，无法记录客户端用户的状态，一般通过 Session来记录客户端用户的状态。

SMTP:简单邮件传输(发送)协议

简单邮件传输(发送)协议基于TCP协议，用来发送电子邮件。

接受邮件的协议是POP3协议

• 电子邮件的发送过程
  比如我的邮箱是“mdl@cszhinan.com”，我要向“xiaomi@qq.com”发送邮件，整个过程简单分为下面几步：

  • 通过SMTP协议，将写好的邮件交给163邮箱服务器（邮局）
  • 163邮箱服务器发现要发送到的邮箱是qq邮箱，它使用SMTP协议将邮件转发到qq邮箱服务器
  • qq邮箱服务器接收邮件后通知邮箱为“xiaoma@qq.com”的用户收邮件，用户通过POP3/IMAP协议将邮件取出

• 如何判断邮箱是真正存在的
  利用SMTP协议判断要发送的邮箱地址是否真的存在：

  • 查找邮箱域名对应的SMTP服务器地址
  • 尝试与服务器建立连接
  • 连接成功后尝试向需要验证的邮箱发送邮件
  • 根据返回结果判断邮箱地址的真实性

POP3/IMAP:邮件接收协议

POP3和IMAP两者都是负责邮件接收的协议。

IMAP协议相比POP3更新一点，为用户提供的可选功能也更多一点,几乎所有现代电子邮件客户端和服务器都支持IMAP。大部分网络邮件服务提供商都支持POP3和IMAP。

FTP:文件传输协议

FTP协议主要提供文件传输服务，基于TCP实现可靠传输。使用FTP传输文件的好处是可以屏蔽操作系统和文件存储方式。

FTP基于C/S模型设计，在客户端与FTP服务器之间建立两个连接。

FTP的原理：

FTP的优势同时也是与其它客户服务器程序最大的不同在于它在两台通信的主机之间使用了两条TCP连接（其它客户服务器应用程序一般只有一条TCP连接）：
控制连接：用于传送控制信息（命令和响应）;
数据连接：用于数据传送；
将命令和数据分开传送的思想大大提高了FTP的效率

Telnet:远程登陆协议

Telnet协议通过一个终端登陆到其他服务器，基于TCP协议。Telnet协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，具有潜在的安全风险。

SSH:安全网络传输协议

SSH是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议，基于TCP 协议。SSH协议可以有效防止远程管理过程中的信息泄露问题。Telnet和SSH的主要区别在于SSH协议会对传输的数据进行加密从而保证数据安全性。

4.2 TCP 三次握手和四次挥手

4.2.1 三次握手

刚开始客户端处于closed状态，服务端处于listen状态。然后

• 第一次握手:客户端发给服务端一个SYN报文，并指明客户端的初始化序列号ISN(c)。此时客户端处于SYN_Send状态。

• 第二次握手:服务器收到客户端的SYN报文后，以自己的SYN报文作为应答，指定了自己的初始化序列号ISN(s)，同时把客户端的ISN+1作为ACK的值，表示已经收到了客户端的SYN报文，此时服务器处于SYN_RCVD状态。

• 第三次握手:客户端收到SYN报文后，发送一个ACK报文，把服务器的ISN＋1作为ACK的值，表示已经收到了服务端的SYN报文，此时客户端处于established状态。

• 服务器收到ACK报文后，也处于established状态，此时，双方建立连接。
  简化总结为：

• 客户端–发送带有SYN标志的数据包–一次握手–服务端

• 服务端–发送带有SYN/ACK标志的数据包–二次握手–客户端

• 客户端–发送带有ACK标志的数据包–三次握手–服务端

为什么要三次握手

三次握手最主要的目的是确认双方的发送与接收是否正常。

第一次握手：Client什么都不能确认；Server确认了：对方发送正常，自己接收正常

第二次握手：Client确认了：自己发送、接收正常，对方发送、接收正常；Server确认了：对方发送正常，自己接收正常

第三次握手：Client确认了：自己发送、接收正常，对方发送、接收正常；Server确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手能确认双方收发功能都正常，缺一不可。

第二次握手为什么要把SYN再传回去

TCP是可靠连接，双方都要确保发送的信息是可靠的、准确无误的。

服务器传回客户端所发送的ACK是证明服务器收到的确实是客户端发送的信号，这表明从客户端到服务端的通信是正常的。

而回传SYN则是为了建立并确认从服务端到客户端的通信。

(ISN)是固定的吗

三次握手的一个重要功能是客户端和服务端交换ISN，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果ISN是固定的，攻击者很容易猜出后续的确认号，因此ISN是动态生成的。

什么是半连接队列

服务器第一次收到客户端的SYN后，会处于SYN_RCVD状态，此时双方还没有完全建立连接，服务器会把此种状态下的请求连接放在一个队列里，这种队列称之为半连接队列。

还有一个全连接队列，即已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了可能出现丢包现象。

关于SYN-ACK重传次数的问题:服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。每次重传等待的时间不相同，一般是指数增长，例如间隔时间为1s,2s,4s,8s

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

第一次、第二次握手不可以携带数据，而第三次握手可以携带数据。

假如第一次握手可以携带数据，如果有人要恶意攻击服务器，那他每次都在第一次握手中的SYN报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，他只需疯狂重复发SYN报文，让服务器花费很多时间、内存空间来接收这些报文。

第一次握手不可以放数据的一个简单原因就是会让服务器更加容易受到攻击。

4.2.2 四次挥手

刚开始双方都处于establised状态，假如是客户端先发起关闭请求,则:

• 第一次挥手:客户端发送一个FIN报文,报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

• 第二次挥手:服务端收到FIN后，发送ACK报文,且把客户端的列号值+1作为ACK报文的列号值，表明已经收到客户端的报文，此时服务端处于CLOSE_WAIT状态。

• 第三次挥手:如果服务端也想断开连接,和客户端的第一次挥手一样,发送FIN报文,且指定一个列号。此时服务端处于LAST_ACK状态。

• 第四次挥手:客户端收到FIN后,发送ACK报文作为应答，且把服务端的序列号值+1作为自己ACK报文的序列号值,此时客户端处于TIME_WAIT状态。需要过一阵子以确保服务端收到自己的ACK报文后才会进入CLOSED状态。

• 服务端收到ACK报文后,处于CLOSED状态。
  简化总结为：

• 客户端-发送FIN，用来关闭客户端到服务器的数据传送

• 服务器-收到这个FIN，发回ACK，确认序号为收到的序号加1。

• 服务器-关闭与客户端的连接，发送FIN给客户端

• 客户端-发回ACK报文确认，并将确认序号设置为收到序号加1
  任何一方都可以在数据传送结束后发出连接释放通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送时，则发出连接释放通知，对方确认后完全关闭TCP连接。

为什么客户端必须等待2MSL的时间

• 第一，为了保证客户端发送的最后一个ACK报文段能够到达服务端。
• 第二，防止 “已失效的连接请求报文段”出现在下一次连接中。客户端在发送完最后一个ACK报文段后，再经过2MSL的时间，可以使本连接持续的时间内所产生的所有报文段都从网络中消失。从而使下一个新的连接中不会出现旧的连接请求报文段。

4.3 TCP和UDP的区别

• TCP面向连接（传输数据前后需要建立和释放连接），UDP无连接
• TCP提供可靠传输，UDP不提供可靠传输
  • TCP的可靠体现在传输数据前，通过三次握手建立连接，数据传输时，有确认、窗口、重传、拥塞控制机制，数据传输后，通过四次挥手释放连接。
• TCP传输数据慢，UDP传输数据快
• TCP面向字节流，UDP面向报文
  • “面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块，但TCP仅仅把这些数据看成一连串无结构的字节流，它不保证接收方收到的数据块和发送方发送的数据块具有对应大小关系。例如，发送方应用程序交给TCP10个数据块，TCP可能只用了4个数据块就把收到的字节流交付给上层的应用程序，虽然数据块大小不同但字节流完全一样。
  • UDP对应用层交下来的报文，不合并,不拆分,保留原报文的边界，添加首部后就向下交付IP层。
• TCP传输数据有序,UDP不保证数据的有序性
• TCP不保存数据边界,UDP保留数据边界
• TCP有流量控制和拥塞控制,UDP没有
• TCP是重量级协议,UDP是轻量级协议
• TCP首部较长20字节,UDP首部较短8字节
• TCP和UDP应用场景不同
  • TCP应用场景:效率要求相对低，对准确性要求相对高的场景。比如文件传输、发送和接收邮件、 远程登录等场景。
  • UDP应用场景:效率要求相对高，对准确性要求相对低的场景。比如QQ语音、在线视频、直播等场景。

4.4 TCP可靠传输的原理

理想的传输条件有以下两个特点：

• 传输信道无差错。
• 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。
  然而实际的网络都不具备以上两个理想条件。必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输。

首先，三次握手建立TCP连接,四次挥手释放TCP连接,从而保证建立的传输信道是可靠的

其次, 采用ARQ协议/自动重传请求协议实现可靠传输,使用滑动窗口协议保证接收方能及时处理所接收到的数据

最后，使用慢开始、拥塞避免、快重传和快恢复进行拥塞控制，避免网络拥塞

4.4.1 ARQ协议

ARQ协议是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ协议包括停止等待ARQ协议和连续ARQ协议。

停止等待ARQ协议

停止等待协议是为了实现可靠传输，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到ACK确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

• 优点： 简单
• 缺点： 信道利用率低，等待时间长

停止等待协议有两种情况：① 无差错情况 ② 出现差错情况

1. 无差错情况

发送方发送分组, 接收方在规定时间内收到, 并且回复确认。发送方再次发送。

2. 出现差错情况（超时重传）

超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式称为自动重传请求ARQ。

确认丢失和确认迟到

确认丢失：确认消息在传输过程中丢失。A发送 M1消息，B收到后向A发送了一个M1确认消息，但在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。

确认迟到：确认消息在传输过程中迟到。A发送 M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，直接丢弃重复的M1。

连续ARQ协议

连续ARQ协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

• 优点：信道利用率高，容易实现，即使确认丢失，也不必重传。
• 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这叫做Go-back-N（回退 N），表示需要退回来重传已发送过的N个分组。

4.4.2 流量控制

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

4.4.3 拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制所要做的前提是网络能够承受现有的网络负荷。

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

  • 防止过多的数据注入到网络中，使网络中的路由器或链路不致过载

  • 一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素
    流量控制

  • 抑制发送端发送数据的速率，以使接收端来得及接收

  • 是点对点通信量的控制，是端到端的问题
    为了进行拥塞控制，TCP发送方要维持一个拥塞窗口(cwnd)的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方的发送窗口为拥塞窗口和接收方的接受窗口中较小的一个。

TCP拥塞控制算法

在网络层可以使路由器采用适当的分组丢弃策略（如主动队列管理AQM），以减少网络拥塞。

• 慢开始：慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
• 拥塞避免：拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间 RTT就把发送方的cwnd加 1。
• 快重传与快恢复：在TCP/IP中，快速重传和恢复（FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有FRR，如果数据包丢失，TCP将使用定时器要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了FRR，如果接收方接收到一个不按顺序的数据段，立即给发送方发送一个重复确认。如果发送方接收到三个重复确认，假定重复确认的数据段已经丢失，并立即重传这些丢失的数据段。有了FRR，不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时，快速重传和恢复能最有效地工作。当有多个数据包在某一段很短的时间内丢失时，它则不能很有效地工作。

4.5 HTTP的状态码

常用状态码

状态码	含义
101	切换请求协议,从HTTP切换到WebSocket
200	请求成功，有响应体
301	永久重定向:会缓存
302	临时重定向:不会缓存
304	协商缓存命中
403	服务器禁止访问
404	资源未找到
400	请求错误
500	服务器端错误
503	服务器繁忙

4.6 各种协议与 HTTP 协议之间的关系

4.7 HTTP如何保存用户状态

HTTP协议自身不对请求和响应之间的通信状态进行保存。Session机制的存在就是为了解决这个问题，Session的主要作用就是通过服务端记录用户的状态。

典型的场景是购物车，当添加商品到购物车时，系统不知道是哪个用户操作的。服务端给特定的用户创建特定的Session后就可以标识这个用户并且跟踪这个用户（一般情况下，服务器会在一定时间内保存这个Session，过了时间限制，就会销毁这个Session）。

在服务端保存Session的方法很多，最常用的就是内存和数据库(比如内存数据库redis)。

• Session存放在服务器端，如何实现Session跟踪？
  • 每次HTTP请求时，客户端都会发送相应的Cookie信息到服务端。大部分情况下，通过在Cookie中附加一个Session ID实现。
• 客户端的浏览器禁用了Cookie怎么办?
  • 利用URL重写，在URL路径后面附加上一个诸如sid=xxxxx这样的参数，服务端据此来识别用户。
• Cookie的作用是什么?和Session有什么区别
  • Cookie和Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不一样。
  • Cookie一般用来保存用户信息。比如①在 Cookie中保存已经登录过的用户信息，下次访问网站时自动把登录的一些基本信息给填了；②一般的网站都会有保持登录，也就是说下次再访问网站时不需要重新登录，因为用户登录时存放了一个Token在Cookie中，下次登录时只需根据Token值来查找用户即可(为了安全考虑，重新登录一般要将Token重写)；③登录一次网站后访问网站其他页面不需要重新登录。
  • Session的主要作用就是通过服务端记录用户的状态。
  • Cookie数据保存在客户端(浏览器端)，是实现Session的一种方式；Session数据保存在服务器端，相对来说Session安全性更高。如果要在Cookie中存储一些敏感信息，不要直接写入Cookie，最好将Cookie信息加密，然后使用时再去服务器端解密。

4.8 URI和URL的区别

URI(Uniform Resource Identifier)是统一资源标志符，唯一标识一个资源。

URL(Uniform Resource Locator)是统一资源定位符，是URI的一个子集，提供该资源的路径。它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

URI的作用像身份证号，URL的作用像家庭住址。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

4.9 地址解析协议ARP

4.9.1 什么是ARP

通信时使用了两个地址

• IP地址（网络层地址）
• MAC地址（数据链路层地址）
  已经知道了一个机器（主机或路由器）的IP地址，如何找出其相应的硬件地址？

ARP就是用来解决这样的问题的：从网络层使用的IP地址，解析出在数据链路层使用的硬件地址。所有的ARP协议在网络层被应用，它是连接网络层与链路层的重要枢纽。

4.9.2 解析的过程

不管网络层使用的是什么协议，在实际网络的链路上传送数据帧时，最终还是必须使用硬件地址

每一个主机都设有一个ARP高速缓存(ARP cache)，里面有所处的局域网上的各主机和路由器的IP地址到硬件地址的映射表

解析的过程

• 主机A欲向本局域网上的某个主机B发送IP数据报时，先在其ARP高速缓存中查看有无主机B的 IP 地址

• 如有，就可查出其对应的硬件地址，再将此硬件地址写入MAC帧，然后通过局域网将该MAC帧发往此硬件地址

• 如没有，就在本局域网广播发送一个ARP请求分组（路由器不转发ARP请求）。收到ARP响应分组后，将得到的IP地址到硬件地址的映射写入ARP高速缓存
  补充

• ARP请求分组包含发送方硬件地址 / 发送方IP地址 / 目标方硬件地址(未知时填0) / 目标方IP地址

• ARP响应分组包含发送方硬件地址 / 发送方IP地址 / 目标方硬件地址 / 目标方IP地址

• ARP分组封装在物理网络的帧中传输

4.9.3 ARP高速缓存的作用

存放最近获得的IP地址到MAC地址的映射，减少ARP广播的次数

• 为了减少网络上的通信量，主机A在发送其ARP请求分组时，将自己的IP地址到硬件地址的映射写入ARP请求分组
• 主机B收到A的ARP请求分组时，将主机A的这一地址映射写入自己的ARP高速缓存中，这样方便主机B以后向A发送数据报

4.10 常见的端口和其对应的服务

端口	服务
21	FTP文本传输协议
22	SSH安全网络传输协议
23	Telnet远程登录协议
53	DNS域名解析协议
80	HTTP超文本传输协议
110	POP3邮件协议
443	HTTPS协议
1080	Sockets
1521	Oracle默认端口
3306	MySQL默认端口