前言

写作于
2022-11-17 20:43:36

发布于
2022-11-20 16:40:32

OSI 七层网络模型

应用层

处理来自应用的数据信息，以支持用户通过用户代理，比如浏览器或者网络接口使用网络。常见的应用层协议有HTTP，HTTPS，DNS、FTP、SMTP。通过这些协议，来将用户的数据，转换成一个机器能看懂的东西。

表示层

对于应用层的数据进行一次处理（例如编码），让两个系统之间可以顺利沟通。 对于应用层传过来的数据进行一次编码转换，确保一个系统的应用层数据能被另一个系统的应用层识别，数据压缩和加密也是表示层可提供的转换功能之一。

会话层

负责建立、管理和终止表示层实体之间的通信会话。对连接进行管理。 这一层的通信由不同设备中的应用程序之间的服务请求和响应组成。同时可以在数据流中插入同步控制点，也就是如果数据传输在某个数据点的附近中断或者发生意外了，会恢复到最近的同步控制点。

传输层

传输层通过TCP、UDP协议建立一个主机端到端的链接。为上层协议提供端到端的可靠透明的数据传输服务，包括处理差错控制和流量控制等问题，并将来自会话层的数据分割成段，构造协议数据单元，传输给网络层。 该层向会话层屏蔽了数据通信的细节。

网络层

通过IP寻址，为收到的数据包在局域网中进行路由操作，传输到对应的目的地。

数据链路层

将比特组合成字节，再将字节组合成帧，通过IP地址根据协议去找到MAC地址，将数据来传输到物理层，并且进行差错检测。

物理

进行最终信号的传输，通过物理介质传输比特流。

七层总结

OSI层	TCP/IP概念模型	功能	设备	TCP/IP协议
应用层	应用层	用户接口、应用程序(文件传输、电子邮件、文件服务、虚拟终端)	网关	TFTP,HTTP,SNMP, FTP,SMTP,DNS,Telnet
表示层	应用层	数据的表示、压缩和加密(数据格式化、代码转换、数据加密)	网关	无协议
会话层	应用层	会话的建立和结束(解除或建立与别的接点的联系)	网关	无协议
传输层	传输层	提供端对端的接口	网关	TCP, UDP
网络层	网络层	为数据包选择路由、寻址	路由器	IP,ICMP,RIP, OSPF, BGP,IGMP
数据链路层	链路层	保证无差错的数据链路，传输有地址的帧以及错误检测功能	交换机、网桥、网卡	SLIP,CSLIP, PPP,ARP,RARP,MTU
物理层	链路层	传输比特流，以二进制数据形式在物理媒体上传输数据	集线器、中继器	ISO2110,IEEE802,IEEE802.2

输入URL后会发生什么

1. DNS域名解析

我们在浏览器输入网址，其实就是要向服务器请求我们想要的页面内容，所有浏览器首先要确认的是域名所对应的服务器在哪里。将域名解析成对应的服务器IP地址这项工作，是由DNS服务器来完成的。

浏览器首先看一下自己的缓存里有没有，如果没有就向操作系统的缓存要，还没有就检查 本机域名解析文件 hosts ，如果还是没有，就会 DNS 服务器进行查询，查询的过程如下：

1. 客户端首先发出一个DNS请求到本地的DNS服务器。本地DNS服务器收到请求后，会到本地缓存中查找，如果有，直接返回其IP地址。如果没有，本地DNS会将请求传递到根域服务器。
2. 根域服务器拿到请求后，发现后置是.com的。会返回对应的 顶级域名服务器 地址。然后本地DNS收到后，又会向这个顶级域名服务器发起请求。
3. 顶级域名服务器收到请求后，会把对应的 权威DNS服务器 的地址返回。本地DNS收到后，继续向这个 权威DNS服务器 发起请求。
4. 权威DNS服务器收到后，查询到对应的IP地址，并告诉本地DNS.
5. 本地DNS再将IP地址返回给客户端。

2. 三次握手建立TCP连接

1. 客户端想要建立连接，给服务器发送建立连接的包(SYN = 1, seq = x)。自己进入SYN_SEND状态
2. 服务器收到消息后，知道客户端想要建立连接，于是给客户端发送确认应答(ACK = 1, ack = x + 1, SYN = 1, seq = y)。然后自己进入SYN_RCVD状态。
3. 客户端收到消息后，知道服务器可以建立连接，那么在此发送确认包(ACK = 1, ack = y+1)，并进入链接状态。服务器收到后也进入连接状态，这样就建立好连接了。

3. 发送HTTP网络请求

与服务器建立连接后，就可以发送HTTP请求了，向服务器请求资源。

4. 服务器处理请求

收到客户端的http请求后，就会web服务器处理，web服务器就会解析用户的请求，知道需要调度哪些资源，然后收集并处理这些资源并将结果返回给客户端。

5. 服务器返回响应

客户端就会收到服务器发回来的响应报文，然后解析这个报文，读取里面的信息。

6. 四次挥手断开TCP连接

1. 首先客户端给服务器发送FIN包(FIN = 1, seq = x)，告诉服务器我的消息发完了，可以断开连接了，但是仍然可以接收数据。客户端进入FIN_WAIT1。
2. 服务器收到后，就会发送一条确认信息(ACK = 1, ack = x + 1)，告诉客户端自己收到刚刚的消息了，但是还没有准备好关闭连接。服务器进入CLOSE_WAIT，客户端收到后进入FIN_WAIT2
3. 然后当服务器准备好关闭连接后，就给客户端发送关闭消息(FIN = 1, seq = y)，然后自己进入LAST_ACK状态。
4. 客户端收到后，就知道可以断开连接了，然后就发送一个确认包(ACK = 1, ack = y + 1)，然后进入TIME_WAIT状态，服务器收到确认包之后，就断开连接，进入CLOSE状态。

客户端进入TIME_WAIT状态后，就会等待两个MSL（报文最大生存时间），如果没有收到服务器端的任何消息，就认为服务器端已经正常关闭了，那么自己也会关闭。

7. 解析HTML

DNS解析过程

DNS解析（域名转换为IP的过程）

在我们输入网址时，使用的都是域名，而不是IP地址。

在域名中，越靠右的位置表示层级越高，所以域名的层级关系类似一个树状结构，以www.server.com举例子：

• 根服务器
• 顶级域DNS服务器（com）
• 权威DNS服务器（server.com）

根域的 DNS 服务器信息保存在互联网中所有的 DNS 服务器中。这样一来，任何 DNS 服务器就都可以找到并访问根域 DNS 服务器了。

因此，客户端只要能够找到任意一台 DNS 服务器，就可以通过它找到根域 DNS 服务器，然后再一路顺藤摸瓜找到位于下层的某台目标 DNS 服务器。

DNS域名解析的工作流程

以[www.server.com]来说。浏览器首先看一下自己的缓存里有没有，如果没有就向操作系统的缓存要，还没有就检查本机域名解析文件hosts，如果还是没有，就会 DNS 服务器进行查询，查询的过程如下：

1. 客户端首先发出一个DNS请求到本地的DNS服务器。本地DNS服务器收到请求后，会到本地缓存中查找，如果有，直接返回其IP地址。如果没有，本地DNS会将请求传递到根域服务器。
2. 根域服务器拿到请求后，发现后置是.com的。会返回对应的 顶级域名服务器 地址。然后本地DNS收到后，又会向这个顶级域名服务器发起请求。
3. 顶级域名服务器收到请求后，会把对应的 权威DNS服务器 的地址返回。本地DNS收到后，继续向这个 权威DNS服务器 发起请求。
4. 权威DNS服务器收到后，查询到对应的IP地址，并告诉本地DNS.
5. 本地DNS再将IP地址返回给客户端。

网络攻击

中间人攻击

中间人攻击就是在A和B网络通信的时候，中间加入了一个恶意攻击者C。C作为中间人转发两者的请求。

1. A向B请求公钥，但是却被C截获。
2. C向B发送公钥请求。
3. B将公钥发给C。
4. C截获了B的公钥，然后替换成自己的公钥发给A。
5. A将C的公钥当成了B的公钥，并用其加密信息，发给B。
6. C截获了加密信息，用自己的私钥解密，获得明文。同时伪造新的信息，再用B的公钥加密，发给B。
7. B获得加密信息，用自己的私钥解密。

SYN泛洪攻击

TCP 连接建立是需要三次握手，假设攻击者短时间伪造不同 IP 地址的 SYN 报文发送给服务端攻击服务端， 服务端每接收到一个 SYN 报文，就进入 SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的 SYN 接收队列（未连接队列，只有收到客户端的ACK报文才会将其移出此队列），使得服务器不能为正常用户服务。

DNS劫持

网站在经过本地DNS解析时，黑客将本地DNS缓存中的www.taobao.com替换成其他网站的ip返回，而客户端并不知情，依旧按照正常流程寻址，建立连接。

在这个过程中，黑客一般是黑进了我们的路由器里，修改了路由器的本地DNS地址，从而访问一个伪造的DNS服务器，这个伪造的服务器解析域名的时候返回错误的ip给我们，当然他要能黑进我们电脑里也可以修改我们的hosts文件

如何解决

手动将浏览器的DNS服务器地址改为通用的DNS地址：8.8.8.8

Http简介/报文格式

Http概述

Http是超文本传输协议，是一个在计算机世界里专门约定和规范在两点之间传输文字、音视频等超文本的约定和规范。

Http优点

• 简单：报文格式和头部信息很简单。为header+body和key-value。
• 灵活且易于扩展：Http协议中的请求方法、URL、状态码、头字段等组成都没有被固定死，允许开发者自定义和扩充。同时HTTP工作在应用层，它的下层可以随意变化。HTTPS也就是在HTTP与TCP层（传输层）之间增加了SSL/TSL安全传输层。
• 应用广泛和跨平台：应用范围广泛，从台式机的浏览器到手机上各种app都用。

Http缺点

1. 无状态（双刃剑）：它的好处是减轻服务器的负担，因为服务器不需要使用额外的资源来记录客户端的状态。坏处是服务器没有记忆客户端的状态，某些一系列操作要知道客户端的信息，每次都需要询问一边客户端的信息进行一次验证信息的操作。（可以使用Cookie解决）
2. 明文传输（双刃剑）：好处是传输时很方便阅读。坏处就是Http的所有信息都暴露出来了，没有隐私可言，很容易被窃取。
3. 不安全：不安全因素分为三点：
   1. 明文传输
   2. 不验证通信方的身份
   3. 无法证明报文的完整性，报文可能会被篡改。

Http报文格式

请求报文

Http的请求报文由请求行、请求头、空行和请求体四部分组成。

请求行：由方法字段、URL字段和HTTP协议版本字段三部分组成。常用的HTTP请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT；

请求头：请求头由关键字/值组成，每行一对，关键字和值中间用：分割，典型请求头有：

● User-Agent：产生请求的浏览器类型;

● Accept：客户端可识别的响应内容类型列表;星号 “ * ” 用于按范围将类型分组，用 “ / ” 指示可接受全部类型，用“ type/* ”指示可接受 type 类型的所有子类型;

● Accept-Language：客户端可接受的自然语言;

● Accept-Encoding：客户端可接受的编码压缩格式;

● Accept-Charset：可接受的应答的字符集;

● Host：请求的主机名，允许多个域名同处一个 IP 地址，即虚拟主机;

● connection：连接方式(close 或 keepalive);

● Cookie：存储于客户端扩展字段，向同一域名的服务端发送属于该域的 cookie

空行：最后一个请求头后面是一个空行，发送回车符号和换行符，通知服务器下面没有请求头了。

请求体：请求体不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客户填写表单的场景。与请求体相关的常使用的是包体类型Content-Type 和包体长度 Content-Length;

响应报文

Http相应报文由状态行、响应头部、空行和响应体四部分组成。

状态行：状态行包括Http协议版本字段、状态码、状态码描述文本三部分组成。

响应头：响应头可能包括：

• Location：用于重定向接受者到一个新的位置。
• Server：包含了服务器用来处理请求的软件信息及其版本。
• Vary：指示不可缓存的请求头列表
• Connection：连接方式;
• WWW-Authenticate：客户端收到 401 响应消息，就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证，就可以 发送一个包含了 Authorization 报头域的请求;

空行：最后一个响应头部之后是一个空行，发送回车符和换行符，通知服务器以下不再有响应头部。

响应体：服务器返回给客户端的文本信息。

Http1.0、HTTP1.1、HTTP2和HTTP3

Http1.1相对于Http1.0的优化

1. 提供了长连接：在Http1.0中默认是短链接，也就是说每次请求都要建立一次连接。建立连接次数太多，意味着三握四挥就越多，所以会有很大开销。因此在Http1.1中默认开启了一个keep-alive，也就是说在keep-alive到期之前，连接会一直存在不会断开。
2. 支持管道运输：也就是说可以进行多条的网络请求，第一条发往服务器的时候，不需要等到相应回来，就可以发送下一个请求，但是服务端必须按照接收顺序返回响应结果，让客户端知道每次请求的相应内容。可以减少整体的响应时间。
3. 缓存方面：在Http1.0中主要使用header中的Expires来做缓存判断。在1.1中添加Cache-Control请求头来控制缓存。
4. 支持了断点续传：在Http1.1中，请求头中添加了Range，允许只请求资源的一部分。
5. 新增了Host字段：在Http1.0当中，认为每台服务器绑定了唯一一个IP。随着虚拟主机的发展，在一个服务器上可能有多个虚拟主机，并且共享一个IP地址，所以新增了hostName。
6. 新增了100状态码：允许客户端发送请求时，对服务端进行一次试探，如果服务端想接收Body请求体，就会返回状态码100，然后客户端再发送请求体Body。

Http1.1会出现的问题

1. 请求/响应头未经压缩就发送，首部信息越多延迟越大。
2. 发送冗长的首部，每次互相发送相同的首部浪费较多。
3. 有队头阻塞的情况
4. 没有设置请求优先级
5. 请求只能从客户端开始，服务端只能被动响应。

Http2相对于Http1.1

1. 头部压缩：如果同时发送请求头相同的请求，会帮助我们消除重复的部分，将重复的部分放入一个头信息表，然后发送头信息表中的索引。
2. 二进制分帧：将传输的数据分割成更小的数据，用二进制编码，将Header存到头信息帧，request Body存到数据帧，增加了解析和传输速率。
3. 多路复用：在一个连接中同时发送多个请求或接收回应。将一个TCP连接分成很多个流，并行发送，这样就解决了Http1.1中产生的队头阻塞问题（服务端按顺序从连接中返回响应）。
4. 服务器推送：服务器不再被动的响应，也可以主动向客户端发送消息。比如：在浏览器刚请求 HTML 的时候，就提前把可能 会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待。

Http2会出现的问题

多个http请求复用一个TCP连接，下层的TCP协议不知道有多少个HTTP请求，所以如果发生丢包，就会触发TCP的重传机制。这样的话TCP中所有的HTTP请求都需要等待丢了的包被重传回来。

Http3.0对于Http2的优化

由于Http2中使用了多路复用，多个http请求复用一个TCP连接，下层的TCP协议不知道有多少个HTTP请求，所以如果发生丢包，就会触发TCP的重传机制。这样的话TCP中所有的HTTP请求都需要等待丢了的包被重传回来。Http3是基于QUIC实现的，QUIC是一个在UDP之上的伪TCP+TLS+HTTP的多路复用协议。

Http 1.0、Http状态码

Http状态码概述

1XX

• 100：客户端应继续其请求
• 101：切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议。

2XX请求成功

• 200：从客户端发送的请求在服务端被正常处理了。
• 204：服务器接受的请求成功处理，但是响应报文的主体部分不包含实体。仅仅有相应。
• 206：客户端进行了范围请求，而服务器成功进行了这部分请求。

3XX重定向

注意：当收到重定向状态码时，所有的post都会变为get，并删除请求报文的主体，之后重新发送。

• 301：永久性重定向。请求的资源分配了新的URL，以后申请时应该去现在所指的新的URL。
• 302：临时重定向。请求的资源临时分配了新的URL，希望本次使用新的URL。
• 304：服务器端资源未改变，可直接使用客户端未过期的缓存。

4XX客户端错误

• 400：请求报文中出现语法错误。
• 401：请求需要有通过Http认证的认证信息。外如果之前已进行一次请求，则表示用户认证失败。
• 403：请求资源被服务器拒绝了。例如没有获得文件系统的访问授权，权限出现问题。
• 404：服务器上没有请求的资源。
• 499：服务器端处理时间过长，客户端主动断开连接。

5XX服务器错误

• 500：服务器执行请求时发生了错误。
• 503：服务器超负荷了或者正在停机维护，现在无法处理请求。

Http断点续传

Http强制缓存和对比缓存

断点续传概述

在上传或者下载文件时，人为的将文件划分为几个部分，每个部分都单独采用一个线程进行上传或者下载。

当网络出现故障又恢复后，可以继续从已经上传或下载的部分开始继续上传或下载。

应用

在HTTP1.1中支持了获取文件的部分内容，断点续传的字段就是Range和Content-Range。

Range用于请求头中，指定第一个字节和最后一个字节的位置。

Accept-Range用于响应头中，用于服务器响应，告诉浏览器是否支持Range

Content-Range用于响应头中，指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。响应数据范围。

出现的问题

在客户端发起请求时，如果URL对应的内容在服务器中已经发生了变化，这样续传下来的数据肯定是错的。这个时候我们就需要用到我们缓存中的字段，比方说Last-Modified或者ETag，但是在断点续传中真正的解决这个问题的字段是If-Range，他在这里面保存了Last-Modified或者ETag的值。

Http强制缓存和对比缓存

强制缓存

强制缓存就是客户端会先从本地缓存中找，找到了判断缓存是否过期，如果过期了再去网络上请求资源。

强制缓存主要是两个字段：Expires和 Cache-control 。

绝对缓存Expires

Expires标识是缓存的到期时间，是一个绝对时间。它对应的是返回的具体的年月日时分秒，客户端从缓存中找到这个时间，如果超过了即过期了的话，就会发送网络请求获取数据。

缺点：当客户端本地修改了时间，缓存就会失效，绝对时间就没有了意义。

相对缓存Cache-control

相对缓存就是Cache-control标识。她返回的是一个倒计时，也就是缓存的有效期。不管客户端本地时间，只要缓存中这个倒计时到0了，客户端才会发送网络请求获取数据。

对比缓存

对比缓存就是每次都会进行网络请求，只不过请求发送到服务器的时候，服务器会根据字段数据判断，是否需要更新数据也就是返回新数据，如果不需要就返回304状态码，让客户端继续使用缓存数据；否则返回200返回数据。

Last-Modified和If-Modified-Since

Last-Modified是服务器返回给客户端的，这个字段是资源最后一次修改的时间。然后客户端在网络请求时通过If-Modified-Since这个字段发送保存的这个时间，然后服务器判断客户端传来的这个时间是否和他需要请求的资源的最后修改时间是否相等，如果相等，就证明资源没有被修改，返回304，客户端可以继续使用缓存；如果不相等，就证明资源被修改了，那就返回200状态码，并将新的资源发送给客户端。

Etag和If-no-match

上一个是修改时间，这个就是标识符。服务器判断标识符是否一致。决定返回304还是200。

GET/POST

GET和POST的区别

1. GET通常是向服务器请求数据，POST通常是向服务器提交数据。
2. GET请求中把参数包在了URL中，明文暴露信息，所以安全性不好；而POST则通过Body请求体传递参数，安全性较高。
3. 浏览器对URL大小有限制，又因为get方法会把参数放到URL中，所以会对get方法有限制。而POST的话，其大小取决于服务器设置。
4. GET只能发送ASCII的数据，而POST没有限制
5. POST会向服务器发送两次请求，发送两个TCP数据包。第一次发送请求头，然后服务器返回100响应码之后，会进行第二次发送，发送请求体，然后服务器再返回200。

如何将get转换为post？

将请求头中的参数放到请求体中，然后分别发送请求头和请求体。

Cookie和Session

首先，在说Cookie和Session之前，要说一下Http的无状态问题，由于Http是无状态的，服务器就不会保存客户端的状态，每次请求，服务端都会认为是一次新的请求，重新确定客户端的身份。

这样耗费性能，所以引入Cookie和Session可以解决。

Cookie

cookie是由服务器发送给客户端的小量信息，以key-value形式存在。

当客户端请求服务器时，如果服务器想记录客户端的状态，就会向客户端浏览器派发一个Cookie，然后客户端浏览器会把Cookie保存起来，下一次进行请求时携带Cookie，服务器通过对Cookie的检查就可以获取到用户客户端的状态。

Session

Cookie弥补了http无状态的问题，Session是在Cookie之后出现的。

与Cookie不同的是，Session是在服务端保存状态的。

当客户端请求创建一个Session时，服务端会检查客户端的请求中是否包含一个SessionID：

• 如果包含，则说明已经为此客户端创建过一个Session了，服务器就会根据SessionID去检索。
• 如果不包含，就会为客户端创建一个Session，并生成一个相关联SessionID返还给客户端。

SessionID一般是一个不会被重复，又不容易被伪造的字符串。保存SessionID的方式经常是Cookie。

Cookie和Session体系

当用户即客户端第一次访问服务器时，服务器响应报头中会有set-Cookie，这就是在客户端本地存放一个Cookie，当用户再次访问服务端时，Http会带着这个cookie过去，Cookie中可能会存放着sessionID这样的信息，让服务器确定是不是属于同一次会话。

Cookie和Session区别

1. 数据存放位置不同：

   cookie数据存放在客户端的浏览器上，session数据放在服务器上

2. 安全程度不同：

   cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。

3. 性能使用程度不同：

   session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能,考虑到减轻服务器性能方面，应当使用cookie。

4. 数据存储大小不同：

   单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，而session则存储与服务端，浏览器对其没有限制。

Http和Https的区别

1. Http是超文本传输协议，明文传输，不太安全；而Https是在http基础上加入了SSL/TLS（安全套接字层），对数据进行加密，是一个加密传输协议具有安全性。（窃听风险）
2. Http传输中不会验证对方的身份，而Https中包含一个证书，证书中包含服务端的主机名。（冒充风险）
3. Http无法验证报文的完整性，容易被篡改，而Https中有数字签名来验证。（篡改风险）
4. Https的连接会较耗费CPU资源，对页面加载和耗电都有影响。
5. Https协议需要CA证书，有点贵。
6. 端口号不同：http是80，https是443。

Https为什么会安全？

对数据进行混合加密（文件内容不能被读取）

对称加密是使用同一个密钥，运算速度快性能好，但是安全性差，传输有可能造成密钥的泄露。

而非对称加密时使用了一对的密钥进行传输，保证了数据的安全性，但是性能差。所以https进行了混合加密的方式。

混合加密就是先用非对称加密生成一个会话密钥，然后使用对称加密通过会话密钥进行数据传输通信。

风险：

虽然无法保证别人解密文件内容，但是中间可以通过截取公钥，来进行文件的伪造，发送篡改错误的文件。

数字签名（内容不能被篡改）

数字签名就是用摘要算法对源文件进行一次摘要并用私钥加密后的内容。

针对混合加密的问题，可以在发送数据时附带上数字签名，然后即使被人窃取篡改，但是接收方可以根据接受的数据运用摘要算法提取出摘要，然后再用发送方公钥解析接收的摘要，进行对比，如果不一致就被篡改了。

风险

中间人可以伪造一个发送方的公钥传给接收方，接收方无法确定自己用的公钥就是发送方提供的。

数字证书（文件不能被掉包）

数字证书简称CA，它由权威机构给某网站颁发的一种认可凭证，这个凭证是被大家（浏览器）所认可的，简单的说就是为公钥做认证的。数字证书里一般会包含公钥、公钥拥有者名称、CA 的数字签名、有效期、授权中心名称、证书序列号等信息。

具体用法：证书中心用自己的私钥，将公钥、公钥拥有者、有效期等证书内容进行加密得到数字证书，然后发送端发给接收端时，接收端用证书中心的公钥解密数字证书，拿到发送端真实的公钥。

摘要算法（计算签名，MD5、SHA算法）

摘要算法不是加密算法（无法通过摘要反推出数据），它用来根据数据生成独一无二的签名，解决了篡改的风险。

摘要算法之所以能指出数据是否被篡改过，就是因为**摘要函数是一个单向函数，计算摘要很容易，但通过摘要反推原数据却非常困难。**而且，对原始数据做一个bit的修改，都会导致计算出的摘要完全不同。摘要算法就是通过摘要函数对任意长度的数据计算出固定长度的摘要。

对称加密和非对称加密

对称加密

对称加密就是通信双方使用同一个密钥，使用加密算法配上密钥进行加密，解密时使用解密算法（加密过程的完全逆过程）配合密钥来进行解密。

经典算法：DES（56位密钥，密钥太短逐渐被弃用）、AES（128、192、256位密钥，现在很流行）

破解思路：

拿到一组或多组原文-密文对，设法找到密钥，这个密钥可以将原文加密为密文，将密文解密位原文，这就成功破解。

缺点

缺点就是密钥泄露，所以不能在不安全的网络上传输密钥，一旦密钥泄露则加密通信失败。

非对称加密

使用公钥对数据进行加密得到密文，使用私钥对数据进行解密得到原数据。

非对称加密就是在网络上将双方的公钥传给对方，然后发消息时对消息使用对方的公钥进行加密、使用自己的私钥进行签名操作，然后接收方根据自己的私钥进行解密并使用对方的公钥对签名进行解析。

非对称加密的特性：

• 对于一个公钥，有且只有一个对应的私钥。
• 公钥是公开的，并且不能通过公钥反推出私钥。
• 可以互相解密：通过私钥加密的密文只能通过公钥能解密，通过公钥加密的密文也只能通过私钥能解密。

经典算法：RSA（可⽤于加密和签名）、DSA（仅⽤于签名，但速度更快）

破解方法

由于⾮对称加密的⾃身特性，怎样通过公钥来推断出私钥通常是⼀种思路（例如RSA），但往往最佳⼿段依然是穷举法，只是和对称加密破解的区别在于，对称加密破解是不断尝试⾃⼰的新密钥是否可以将⾃⼰拿到的原⽂-密⽂对进⾏加密 和解密，⽽⾮对称加密时不断尝试⾃⼰的新私钥是否和公钥互相可解。

SSL/TLS握手

SSL/TLS基本流程

• 客户端向服务端索要并验证服务器的公钥
• 双方协商生产出会话密钥
• 双方采用会话密钥进行通信

SSL/TLS握手流程

1. ClientHello

   首先由客户端发起加密通信请求，也就是 ClientHello 请求。在这一步，客户端主要向服务器发送客户端支持的 **TLS 协议版本,客户端支持的密码套件列表（ 加密算法，hash算法，压缩算法等）,同时会发送一个随机数，**用于后面生产「会话秘钥」。

2. ServerHello

   服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。主要发送如下内容：确认 TLS 协议版本，确认的密码套件列表，服务器生产的随机数，以及服务器的数字证书。

3. 客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的CA公钥，确认服务器数字证书的真实性。如果服务器没有问题，就会从数字证书中取出服务器的公钥，然后使用它加密一个随机数发送 ，随后会发送 加密算法改变通知 和 客户端握手结束通知。

4. 服务端最后回应

   收到客户端的随机数后，会**使用这三个随机数，通过协商的加密算法，计算出本次的会话密钥。**然后向客户端发送 加密算法改变通知 和 服务器握手结束通知。

5. 服务端计算之前所有接收信息的 hash 值，并用会话密钥进行加密发送给客户端

6. 客户端计算之前所有接收信息的 hash 值，并用会话密钥进行加密发送给服务端

7. 开始使用协商密钥与算法进行加密通信。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用加密内容。也就是就是TCP三次握手过程。

RSA算法

第一步：生成秘钥对，即公钥和私钥

1：随机找两个质数 P 和 Q ,P 与 Q 越大，越安全。(随机找两个质数)

比如 P = 67 ，Q = 71。计算他们的乘积 n = P * Q = 4757 ，转化为二进为 1001010010101，该加密算法即为 13 位，实际算法是 1024 位 或 2048 位，位数越长，算法越难被破解。

2：计算 n 的欧拉函数 φ(n)。(m = φ(n) = (P-1)(Q-1) )

φ(n) 表示在小于等于 n 的正整数之中，与 n 构成互质关系的数的个数。例如：在 1 到 8 之中，与 8 形成互质关系的是1、3、5、7，所以 φ(n) = 4。 如果 n = P * Q，P 与 Q 均为质数，则 φ(n) = φ(P * Q)= φ(P - 1)φ(Q - 1) = (P - 1)(Q - 1) 。 本例中 φ(n) = 66 * 70 = 4620，这里记为 m， m = φ(n) = 4620

3：随机选择一个整数 e，条件是1< e < m，且 e 与 m 互质。

公约数只有 1 的两个整数，叫做互质整数，这里我们随机选择 e = 101 请注意不要选择 4619，如果选这个，则公钥和私钥将变得相同。

4：有一个整数 d，可以使得 e* d 除以 m 的余数为 1。( e* d%m=1)

但是注意e不能和d一样，这样就会导致公钥和私钥一样。

5：生成公钥和私钥

公钥：(n,e)

私钥：(n,d)

第二步：加密解密

1：加密

$$a^e\mathrm{m}\mathrm{o}\mathrm{d}n=b（a是明文，b是密文）$$

2：解密

第一步：生成秘钥对，即公钥和私钥

1：随机找两个质数 P 和 Q ,P 与 Q 越大，越安全。(随机找两个质数)

比如 P = 67 ，Q = 71。计算他们的乘积 n = P * Q = 4757 ，转化为二进为 1001010010101，该加密算法即为 13 位，实际算法是 1024 位 或 2048 位，位数越长，算法越难被破解。

2：计算 n 的欧拉函数 φ(n)。(m = φ(n) = (P-1)(Q-1) )

φ(n) 表示在小于等于 n 的正整数之中，与 n 构成互质关系的数的个数。例如：在 1 到 8 之中，与 8 形成互质关系的是1、3、5、7，所以 φ(n) = 4。 如果 n = P * Q，P 与 Q 均为质数，则 φ(n) = φ(P * Q)= φ(P - 1)φ(Q - 1) = (P - 1)(Q - 1) 。 本例中 φ(n) = 66 * 70 = 4620，这里记为 m， m = φ(n) = 4620

3：随机选择一个整数 e，条件是1< e < m，且 e 与 m 互质。

公约数只有 1 的两个整数，叫做互质整数，这里我们随机选择 e = 101 请注意不要选择 4619，如果选这个，则公钥和私钥将变得相同。

4：有一个整数 d，可以使得 ed 除以 m 的余数为 1。( ed%m=1)

但是注意e不能和d一样，这样就会导致公钥和私钥一样。

5：生成公钥和私钥

公钥：(n,e)

私钥：(n,d)

第二步：加密解密

1：加密

$$a^e\mathrm{m}\mathrm{o}\mathrm{d}n=b（a是明文，b是密文）$$

2：解密

$$a^e\mathrm{m}\mathrm{o}\mathrm{d}n=b（a是密文，b是明文）$$

TCP/UDP介绍以及对比

TCP概述

TCP传输控制协议是一种面向连接的、可靠的字节流服务。大部分应用使用的正是 TCP 传输层协议，比如 HTTP 应用层协议。相比于UDP而言，TCP提供了流量控制、拥塞控制和丢包重传机制等功能。实现了可靠性的传输

应用场景

通信效率要求相对不高，对准确性要求高。例如：文件传输、接收邮件、远程登陆等等。

UDP概述

UDP用户数据报协议，是**无连接的。面向报文，只负责发送数据包，不保证数据包是否能抵达对方，但它实时性相对更好，传输效率也高。**当然，UDP 也可以实现可靠传输，把 TCP 的特性在应用层上实现就可以，不过要实现一个商用的可靠 UDP 传输协议，也不是一件简单的事情。

应用场景

通信效率要求高、要求网络通讯速度尽量快，但是对准确性以及通讯质量要求相对较低的场景。例如：QQ聊天、在线视频、广播通信等等。

TCP报文结构

序列号（seq）：建立连接时由计算机生成的随机数作为初始值，通过SYN请求包传给接收端主机，每发送一次数据，就累加一次该大小，可以解决网络包乱序的问题。

确认应答号（ACKnum）：下一次「期望」收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决不丢包的问题。

控制位：

ACK：取1时说明为响应报文，TCP报文段中会存放确认应答号。TCP 规定除了最初建立连接时的SYN 包之外该位必须设置为 1 。

RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。

SYN：该位为 1 时，表示希望建立连接，并在其序列号的字段进行序列号seq初始值的设定。

FIN：该位为 1 时，表示表示数据传送完成。今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位置为 1 的 TCP 段。

URG：TCP包的紧急指针字段有效，用来保证TCP连接不被中断，并且督促中间设备尽快处理这些数据。

PSH：PUSH功能。指数据包到达接收端之后，立即送给应用程序，而不是在缓冲区中排队。

16位接收窗口：目的主机使用16位的窗口字段来告诉源主机他期望每次收到的字节数。

16位校验和：源主机基于部分IP头信息，TCP头信息和数据内容计算一个校验和，目的主机也要计算，如果内容没有错误，则两个计算应该一样，从而证明数据的有效性。

16位紧急指针：只有在URG被设置时才有效。

UDP报文格式

目标和源端口：主要是告诉 UDP 协议应该把报文发给哪个进程。

包长度：该字段保存了 UDP 首部的长度跟数据的长度之和。

校验和：校验和是为了提供可靠的 UDP 首部和数据而设计。

TCP与UDP的区别

1. 连接：TCP面向连接，传输数据前提是建立连接；UDP是无连接的，即刻传输。
2. 服务对象：TCP是一对一的两点服务；UDP支持一对一、一对多、多对多的交互通信。
3. 可靠性：TCP是可靠交付数据的，数据可以做到无差错、不丢失、不重复并且按需到达。而UDP是尽最大努力进行交付，不保证可靠性。
4. 首部开销：TCP首部长度长，UDP短只有8字节。
5. 拥塞控制、流量控制：TCP有拥塞控制和流量控制机制，可以保证数据传输的安全性；而UDP则没有，即使网络非常拥堵，UDP也会一直发不受影响。
6. 传输数据报大小：
   1. TCP建立在两端连接之上的协议，理论上应该没有限制，但是由于缓冲区大小有限制，所以TCP协议会把数据截成好几段，接收方依次接收。
   2. UDP本身发送就是一份一份的数据报，自然有一个上限大小64k。
7. TCP面向字节流，UDP面向数据报。

TCP如何保证可靠传输

校验和

在发送数据之前计算校验和，并进行TCP报文中校验和的填充。接收方收到数据之后，对数据进行同样的校验和计算，求出校验和与发送方做一个对比。检测数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。

---

P80

因特网检验和(Internet checksum)就基于这种方法:将传输数据中的每两个字节作为一个16比特的整数对待并连续两两求和,这个和的反码就形成了因特网检验和。看下面的例子,假定有3个16比特的字:
1100011001100110
1111010101010101
1000111100001100
前两个字之和有溢出;该1就要被加到最低位上(称为回卷):1011101110111100,将其再与第三个字相加,得到1011010010110001(仍有回卷)。求反码的运算是将所有的0换成1,所有的1转换成0。因此,值1011010010110001的反码运算结果是0100101101001110,这就得到了检验和。在接收方,企部的4个16比特的室(原先3个字加上检验和)一起相加。如果分组无差错,则在接收方这个和将是111111u1111。如果其中一个比特为0,就知道分组中出现了差错。

---

序列号确认应答机制

序列号：TCP传输时，将每个字节的数据都进行了编号，这就是序列号，序列号的作用不仅仅是应答，有了序列号能够将接收到的数据序列号排序，并且去掉重复序列号的数据。

确认应答：TCP传输过程中，每次接收方收到数据后，都要对传输方进行应答。也就是发送ACK报文，这个ACK报文中带有对应的确定序列号，可以告诉发送方，接收了什么数据，下一次数据从哪里发。

超时重传

如果发送发迟迟未收到确认应答，那么可能是发送 的数据丢失，也可能是确认应答丢失，这时发送方在等待一定时间后会进行重传。TCP会在以下两种情况发生超时重传：数据包丢失、确认应答丢失

快速重传

快速重传机制不以时间为驱动，而是以数据驱动重传。当接收方连续三次收到相同的ACKnum确认序号时，就会认为有一个数据报没有没响应，就会重传丢失的这个数据报。

如果发送方发送了1，2，3，4，5份数据：

TCP的三握四挥

TCP的三次握手

1. 第一次握手：客户端想要建立连接，给服务器发送建立连接的包(SYN = 1, seq = x)。指明客户端打算连接服务器的端口，以及初始化序列号为x，保存在包头的序列号字段中。自己进入SYN_SEND状态
2. 第二次握手：服务器收到消息后，知道客户端想要建立连接，于是给客户端发送确认应答包(ACK = 1, ack = x + 1, SYN = 1, seq = y)。然后自己进入SYN_RCVD状态。
3. 第三次握手：服务器收到消息后，知道客户端可以建立连接，于是给客户端发送确认应答包(ACK = 1, ack = y + 1,)。进入连接状态。

相关问题

为什么不是两次握手？

1. 无法防止历史重复连接的建立。会造成资源浪费。比如客户端发送了一个SYN报文。但是由于此时网络拥堵，这个包滞留在了网络中而迟迟没有到达，这样由于TCP的重传机制，他就会又发送一个Syn包过去。由于是两次握手，服务器不清楚客户端是否收到了自己发送的建立连接的ACK确认信号，所以每收到一个SYN就只能先主动建立一个连接，这样服务器在收到请求后就会建立多个无效连接，造成不必要的资源浪费。且如果在旧 SYN 报文到服务器之前，客户端已经断开了，此时就会出错。

   而如果是三次就不会出现这个问题，在三次握手中，如果新的SYN报文被服务器处理之后，旧的SYN报文到服务器了，此时服务器就会回一个SYN+ACK报文给客户端。客户端收到后可以根据自己的上下文，判断出这是一个历史连接（序列号过期或超时），那么客户端就会发送RST报文给服务端，表示中止这一次的连接。

2. 三次握手才可以同步双方的初始序列号。

   当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。

为什么不是四次握手？

造成了浪费，三次已经建立可靠连接了，没必要四次。

为什么每次初始序列号seq是不相同的？

因为网络中的报文会延迟、会复制重发、也有可能丢失，这样会造成的不同连接之间产生互相影响，所以为了避免互相影响，客户端和服务端的初始序列号是随机且不同的。

回传了SYN信号为什么还要传ACK？

TCP是可靠连接，双方都要确保发送的信息是可靠的、准确无误的。回传了SYN是服务器想和客户端连接，ACK信号是服务器确认收到了客户端的信息。双方确认才会可靠准确。

TCP的四次挥手

1. 首先客户端给服务器发送FIN包(FIN = 1, seq = x)，告诉服务器我的消息发完了，可以断开连接了，但是仍然可以接收数据。客户端进入FIN_WAIT1。
2. 服务器收到后，就会发送一条确认信息(ACK = 1, ack = x + 1)，告诉客户端自己收到刚刚的消息了，但是还没有准备好关闭连接。服务器进入CLOSE_WAIT，客户端收到后进入FIN_WAIT2
3. 然后当服务器准备好关闭连接后，就给客户端发送关闭消息(FIN = 1, seq = y)，然后自己进入LAST_ACK状态。
4. 客户端收到后，就知道可以断开连接了，然后就发送一个确认包(ACK = 1, ack = y + 1)，然后进入TIME_WAIT状态，服务器收到确认包之后，就断开连接，进入CLOSE状态。

相关问题

为什么要四次挥手？

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

所以服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和FIN 一般都会分开发送，从而比三次握手导致多了一次。

为什么要有时间等待计时器（TIME_WAIT 状态）？

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。需要时间等待计时器主要有两方面的原因：

1. 防止下一个新建立的连接接受旧的数据包。如果没有TIME_WAIT 或者 TIME_WAIT 太短，就会有一种情况，连接已经关闭，但是之前的报文被网络延迟了，这时如果有相同的端口TCP连接，这个旧报文可能会经过这个连接到达客户端，这样就发生了数据错乱等严重问题。所以TCP设计出了这样一个机制，经过2MSL，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自动消亡，再出现的数据包一定是新建立连接所产生的。
2. 保证能让服务端（即被动关闭连接的一方）能被正确的关闭，保证最后的ACK能让被动关闭方接收，从而帮助它正常关闭。

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

MSL是报文最大生存时间，超过这个时间的报文将会被丢弃。而时间等待计时器等待2MSL，是因为如果被动关闭方没有收到最后的ACK报文，就会触发超时重发FIN报文，这样一来一回正好是2个 MSL。

2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。

MSL如何计算得出？

因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。

MSL 与 TTL 的区别：MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

如果连接建立之后，客户端突然出现故障怎么办？

有个 保活计数器。 定义一个时间段，默认为2小时，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔75秒，发送一个探测报文，该探测报文包含的数据非常少，如果连续9个探测报文都没有得到响应，服务器就认为客户端出了故障，接着就关闭连接。

TCP重传机制

TCP重传机制概述

重传机制是用来解决数据包丢失的情况

常见的重传机制有：

• 超时重传
• 选择重传
• SACK
• D-SACK

超时重传

在发送数据的时候，设定一个计时器，当超过指定的时间之后，没有收到对方传回的ACK确认应答报文，就会重发该数据，这就是超时重传机制。

超时时间应该设置为多少呢？

这里有个往返时延(RTT),就是也就是数据包从发出去到收到对应 ACK 的时间。RTT 是针对连接的，每一个连接都有各自独立的 RTT。由于网络是波动的，还有可能出现网络延迟，所以这里会用 指数加权移动平均 的方法来得到一个平滑的 RTT 估计值。

而超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP 的策略是超时间隔加倍。也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。

超时重传的缺点

1. **基于计时器，往往要等待很长时间。**如果数据丢失了我们还要等待计时器时间到才可以继续重传。
2. 比较低效。无法判断要重传多少数据包，会把后面的数据报都重传。

快速重传

快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。

比如说4，5，6，7，8四个数据包，5这个数据包在传输的过程中丢失了，收到乱序的包 6,7,8 时，服务器全都发 ACK = 5。这样，客户端就知道 5 发生了空缺。

这解决了超时重传机制需要等待很长时间的问题。但是还是无法解决：到底该重传多少个包？

缺陷：

还是无法判断到底要重传多少数据包。

SACK（带选择确认的重传）

SACK特性是TCP的一个可选特性，是否 启用需要收发双发进行协商，如果双发都支持，那么后续连接态通信过程中就可以使用SACK选项了。这种方法是基于快速重传的，当触发快速重传机制后，客户端就可以通过服务端的SACK 信息发现丢失的数据段，则重发时，就只选择这个 TCP 段进行重复。

如下图，发送方收到了三次同样的 ACK 确认报文，于是就会触发快速重发机制，通过SACK 信息发现300—-600部分已经接收，只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进行重复。

DSACK

重复发送SACK，这个机制是在 SACK 的基础上，额外携带信息，告知发送方有哪些数据包自己重复接收了。DSACK 的目的是帮助发送方判断，是否发生了 包失序、ACK 丢失、包重复或伪重传。 让 TCP 可以更好的做网络流控。

TCP滑动窗口协议/实现流量控制

TCP流量控制概述

控制发送方发送速率，让「发送方」根据「接收方」的实际接收能力控制发 送的数据量，这就是所谓的流量控制。

滑动窗口协议

它可以让发送端在一定的范围内，无需等待确认应答，而继续发送数据。

首先接收方会根据自己的缓存区大小确定窗口大小，然后放在TCP头部的window字段中传递给发送方。

发送方拿到之后，就根据 这个窗口大小 和 拥塞控制的窗口大小 来确定 自己的窗口大小。只要不超过这个窗口大小，就可以一直给接受方发送数据而无需确认应答。并且这些发送的数据会存放在发送方的缓存空间中，只有按期收到确认应答，数据才可以从缓存区清除，并且把发送方的滑动窗口向后移动，继续发送未发送但在接收方处理范围之内的数据。如果触发了重传机制，比如超时重传，或者快速重传，就会使用这里的数据对需要重传的进行重传。

接收方拿到数据后先放到了自己的缓存区里，然后根据自己的处理情况对缓存区中的数据进行处理，并把新的缓存区大小也就是窗口大小和ACK包一块返回给接收方。重复上述过程。

滑动窗口的优点

• 提高效率，如果没有这些“窗口”，那么 TCP 每发送一段数据后都必须等到接收端确认后才能发送下一段数据，这样做的话 TCP 传输的效率实在是太低了。
• 流量控制，为了控制发送方发送速率，让「发送方」根据「接收方」的实际接收能力控制发送的数据量

滑动窗口实现流量控制

如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。**为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。**流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。

滑动窗口协议（连续ARQ协议）实现。滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。

接收窗口和发送窗口的大小是相等的吗？

因为如果接收方读取处理数据非常快的话，有可能上一秒发送的响应报文中窗口大小是x，但是下一秒当客户端还没有发送响应报文之前又进行了数据的读取，此时会造成接收窗口变大 ，所以这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。

窗口为0时的情景，以及会出现的问题

如果窗口大小为0时，就会阻止发送方给接收方传递数据，直到窗口变为非0为止。

但这是有潜在危险的，接收方通知客户端窗口大小的数据报，是ACK包，我们都知道，针对ACK包，是不用恢复确认报文的，所以如果服务端通知客户端窗口大小非0的报文意外丢失，服务端就会一直等待客户端向它发送数据，而客户端的窗口大小仍然为0，这就造成了死锁。

解决方法

TCP 为每个连接设有一个持续定时器，只要 TCP 连接一方收到对方的零窗口通知，就启动持续计时器。如果持续计时器超时，就会发送窗口探测 ( Window probe ) 报文，而对方在确认这个探测报文时，给出自己现在的接收窗口大小。如果接收窗口仍然为 0，那么收到这个报文的一方就会重新启动持续计时器；窗口探查探测的次数一般为 3 次，每次大约 30-60 秒（不同的实现可能会不一样）。如果 3 次过后接收窗口还是 0 的话 ，有的 TCP 实现就会发 RST 报文来中断连接。

TCP拥塞控制

拥塞控制概述

在网络出现拥堵时，如果继续发送大量的数据包，可能导致数据包延迟、丢失等，这时TCP就会重传数据，但是一重传就会导致网络负担更重，于是会导致更大的延迟和更多的丢包，这个情况就会进入恶行循环不断的放大。

于是，就有了拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络。

当网络发生拥塞时，TCP会自我牺牲，降低发送的数据量。

为了在发送方调节发送数据的量，定义了一个叫拥塞窗口cwnd的概念，它是发送方维护的一个状态变量，它会根据网络的拥塞程度动态变化。

什么是拥塞窗口？

拥塞窗口 cwnd 是发送方维护的一个 的状态变量，它会根据网络的拥塞程度动态变化的。

发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，引入了拥塞窗口的概念后，发送窗口的值就变成了是拥塞窗口和接收窗口中的最小值。

怎么知道当前网络是否出现了拥塞呢？

发生了超时重传，就会认为网络出现了拥塞。

拥塞控制算法

• 慢启动
• 拥塞避免
• 拥塞发生
• 快速恢复

慢启动

TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据包的数量。比如连接建立完成后，一开始初始化拥塞窗口大小为1。每收到一个ACK响应，都扩大为原来的2倍。发包的个数是指数性的增长。

但是这个拥塞窗口大小并不是无限制一直增长的，有一个叫慢启动阈值 ssthresh （slow start threshold）状态变量。

• 当 cwnd < ssthresh 时，使用慢启动算法。
• 当 cwnd >= ssthresh 时，就会使用「拥塞避免算法」。

但是TCP在通信开始时，TCP初始化为65535个字节，这个是TCP设计的一个阈值。但是如果触发重传机制后，会把慢启动阈值设置为当时拥塞窗口大小的一半。

拥塞避免

当拥塞窗口 cwnd 「超过」慢启动阈值 ssthresh 就会进入拥塞避免算法。它的规则是：每当收到一个 ACK 时，cwnd 增加1，变成了线性增长。

拥塞发生

当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：

• 超时重传
• 快速重传

这两种使用的拥塞发送算法是不同的。

发生超时重传的拥塞发生算法：当发生了「超时重传」，这个时候，会把 阈值 设为 出现拥塞时的发送窗口大小的一半 （乘法减小），拥塞窗口大小 重置为1。接着就重新开始慢启动。

发生快速重传的拥塞发生算法：TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分。 阈值 变为 出现拥塞时的拥塞窗口大小的一半 （乘法减小），拥塞窗口大小 同样设置为原来的一半。然后进入快速恢复算法。

快速恢复

快速重传和快速恢复算法一般同时使用，快速恢复算法是认为，你还能收到 3 个重复 ACK 说明网络也不那么糟糕。在进入快速恢复算法之前，cwnd 和 ssthresh已经更新了。然后，进入快速恢复算法如下：

• 拥塞窗口 cwnd = ssthresh + 3 （ 3 的意思是确认有 3 个数据包被收到了）
• 重传丢失的数据包
• 如果再收到重复的 ACK，那么 拥塞窗口大小 增加 1
• 如果收到新数据的 ACK 后，接着就进入了拥塞避免算法，即就是线性增长。

TCP粘包拆包

什么是粘包拆包？

正常情况下，发送端发两个数据包，接收端正常收到两个数据包。

粘包情况下，发送端发送两个数据包，而接收端只接收了一个，由于TCP不会丢包，所以这时就是这一个数据包中包含了发送的两个数据包的信息，这现象就是粘包。由于接收端不明白两个数据包的界限，就很难处理。

拆包情况下，发送端发送两个数据包，而接收端收到了两个数据包，但是这两个数据包要么不完整，要么多出来一块，也就是既发生了粘包也发生了拆包。

发生粘包拆包的原因

1. 应用程序写入的数据大于套接字缓冲区大小，这就会发生拆包
2. 应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发到网上，这就会发生粘包。
3. 进行MSS（最大报文长度）大小的TCP分段，当TCP报文长度-TCP头部长度>MSS的时候将发生拆包
4. 接受方法不及时读取套接字缓冲区数据，这就会发生粘包。

发送端原因：由于TCP协议本身的机制，客户端会与服务端维持一个连接，在连接不断开的情况下，可以持续的发送多个数据包，如果发送的网络数据包太小，就会气筒Nagle算法，对较小的数据包进行合并然后再发送，这样就会造成粘包。

接收端原因：服务器接收到数据后，放到缓冲区中，如果消息没有及时从缓冲区取走，下次取数据时就会出现一次取出多个数据包的情况，这样也会造成粘包现象。

解决方法

1. 发送端给每个数据包添加包首部，首部中至少包含数据包的长度，这样接收端接收数据后，通过读取每个数据包的长度，就可以知道每一个数据包的实际长度了，就可以区分粘包中数据包的界限。
2. 发送端将每个数据包封装为固定长度（不够的通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据，自然就会把每个数据包拆分开。
3. 可以在数据包之间添加边界，如特殊符号。这样接收端就可以将不同的数据包拆分开。

四大计时器

TCP协议的四大计时器

重传计时器

在一个TCP连接中，TCP每发送一个报文段就对此报文段设置一个超时重传计时器。若此计时器截止时还没有收到此报文段的确认报文，则重传此报文段，并将计时器复位。

持续计时器

为了解决0窗口大小造成的死锁。

当接收端宣布窗口大小为0时，发送TCP就会停止发送报文，直到接收端确认并宣布了一个非0大小的窗口。但是这个确认可能丢失，如果这个确认丢失，双方的TCP将会永远等待对方，称为了死锁。

要打开这个死锁，就启动了持续计时器，当持续计时器时间到了之后，发送端就发送一个特殊报文段，叫做探测报文段。探测报文段会告诉对端，确认已经丢失，必须重传。

保活计时器

保活计时器用来防止两个TCP之间的连接出现长时期的空闲。

如果客户打开了到服务器的连接，传送了一些数据，然后就保持静默。在这种情况下，这种连接将永远的处于打开状态。保活计时器每隔一段时间超时之后，会检查连接是否空闲太久了，如果空闲的时间超过了设置时间就会发送探测报文。然后通过对端是否响应、响应是否符合预期，来判断对端是否正常，如果不正常就主动关闭连接，而不用等待HTTP层的关闭。

时间等待计时器

时间等待计时器时在连接终止时使用的。（TIME_WAIT）

当TCP关闭一个连接时，他并不认为连接马上就真正关闭。在等待期间，连接处于一种中间过渡阶段，这就可以是重复的FIN报文段可以到达目的地。这个计时器的值通常设置为一个报文段的寿命期期待值的两倍。

IP基本认识

IP的概述

IP协议是TCP/IP协议簇中的核心协议，也是TCP/IP的载体。所有的TCP，UDP，ICMP以及IGMP数据都要以IP数据报的格式传输。

网络层最常使用的就是IP协议，IP协议会将传输层的报文作为数据部分，再加上IP包头组成IP报文。如果该IP报文大小超过了MTU（以太网中一般为1500字节）就会进行分片操作，得到真正要发送到网络的IP报文。 网络层就是通过IP协议进行寻址和路由，最终将报文发送给目标主机。

IP特点

是不可靠的、无连接的数据传送服务。

• 不可靠：不能保证IP数据报能成功到达目的地。当发生某种错误时，如某个路由器暂时用完了缓冲区，IP会丢弃该数据报，然后发送ICMP消息给信源。任何要求的可靠性必须由上层来提供。
• 无连接：**不维护任何关于后续数据报的状态信息。所以不用创建连接。**每个数据报的处理是相互独立的。IP数据报可以不按发送顺序接收。

IP数据包格式

一个 IP 数据包由 IP头 和 数据 两部分组成，IP头的前一部分是固定长度，共20字节，是所有IP数据报必须具有的。在固定部分的后面是一些可选字段，其长度是可变的。

版本：占 4 bit，指IP协议的版本，目前的 IP 协议版本号为 4 (即 IPv4)

首部长度：占 4 bit，可表示的最大数值是 15 个单位(一个单位为 4 字节，一个字节8个bit)，因此 IP 的首部长度的最大值是60字节。而固定部分占据20字节

总长度：占 16 bit，指首部和数据之和的长度，单位为字节，因此数据报的最大长度为 65535 字节。总长度必须不超过最大传送单元 MTU。

标识(identification) ：占 16 bit，它是一个计数器，用来产生数据报的标识。

标志(identification) ：占 3 bit，用于分片。

片偏移(13 bit)：较长的分组在分片后，某片在原分组中的相对位置。片偏移以 8 个字节为偏移单位。

生存时间(8 bit)：记为 TTL (Time To Live)，数据报在网络中的寿命。

协议(8 bit)：字段指出此数据报携带的数据使用何种协议，以便目的主机的 IP 层将数据部分上交给哪个处理过程。

首部检验和(16 bit)：字段只检验数据报的首部不包括数据部分。数据包每经过一个中间节点都要重新计算首部校验和，对首都进行检验。

源地址和目的地址：都各占 4 字节。

首部检验和的计算过程

字段只检验数据报的首部不包括数据部分。数据包每经过一个中间节点都要重新计算首部校验和 (一些字段,如生存时间,标志,片偏移等都可能发生变化),，对首都进行检验。

首先把检验和字段置为 0 。然后，对首部中每个 16 bit 进行二进制反码求和（整个首部看成是由一串 16 bit的字组成），结果存在检验和字段中。当收到一份I P数据报**后，同样对首部中每个 16 bit进行二进制反码的求和。**由于接收方在计算过程中包含了发送方存在首部中的检验和，因此，如果首部在传输过程中没有发生任何差错，那么结果全为1。如果结果不是 （即检验和错误），那么IP就丢弃收到的数据报。

IP地址的分类

IP地址概述

IP地址（IPV4）由32位正整数表示，IP地址在计算机中是以二进制的方式处理，但是人们位了方便记忆采用了点分十进制的标记方式，也就是将IP地址每8位一组，分为4组，每组间以**「.」**隔开，再将每组转换成十进制。

IP地址分类

每个IP地址包括两个标识码，即 网络号 和 主机号。同一个物理网络上的所有主机使用同一个网络号，每一个主机（包括网络上工作站，服务器和路由器等）有一个主机号与其对应。

IP地址根据网络号的不同分为5种类型，A类地址、B类地址、C类地址、D类地址和E类地址。

A，B，C 类的IP地址主要分为两部分。分别是网络号和主机号。 比如对于A类IP地址来说，它的第一位为0，网络号有7位，主机号有24位。对应的IP地址范围为0.0.0.0~127.255.255.255。 最大主机数位2^24 -2 (减去两个特殊的。主机号全为 1 指定某个网络下的所有主机，用于广播。主机号全为0 表示一个网段)

D 类和 E 类地址是没有主机号的，所以不可用于主机 IP，D 类常被用于多播，E 类是预留的分类，暂时未使用。

广播与多播

广播 ：用于在同一个链路中相互连接的主机之间发送数据包。广播无法穿透路由器。分为本地广播和直接广播两种。

多播 ：多播用于将包发送给特定组内的所有主机。可以穿透路由器。

为什么分离网络号和主机号

两台 计算机要通讯，首先要判断是否处于同一个广播域内，即网络地址是否相同，是否存在于同一个局域网内。只有网络地址相同，才可以把数据直接发送到目标主机。路由器寻址工作中，也就是通过这样的方式来找到对应的网络号的，进而把数据包转发给对应的网络内。

无分类地址 CIDR

如果单单使用五类地址有个问题，比如需要10000个主机数量的IP地址供企业使用，如果使用C类地址只有254个主机太少了，而使用B类地址的话最大主机数量达到6万多，又太多了造成浪费。 这种情况可以用CIDR地址解决。

这种方式不再有分类地址的概念，32 比特的 IP 地址被划分为两部分，前面是网络号，后面是主机号。（表示形式 a.b.c.d/x，其中 /x 表示前 x 位属于网络号， x 的范围是 0 ~ 32，这就使得 IP 地址更加具有灵活性。）

子网掩码的作用

1. 子网掩码用来**区分网络号和主机号：**将子网掩码和 IP 地址按位与计算 ，就可得到网络号。
2. **划分子网：**在传统的IP分类地址中，同一网络下是没有地址层次的。比如说一个公司里使用了B类地址，如果想按不同的岗位细分不同的网络地址实现起来是比较困难的。所以直接用A类，B类，C类会形成资源浪费，且灵活性差。引入子网掩码后，可以将原来A类，B类，C类的部分主机号用作子网地址，从而细分出比A类，B类，C类粒度更小的网络。

子网划分实际上是将主机地址分为两个部分：子网网络地址和子网主机地址。

IPV6基本认识

IPv6 的地址是 128 位的。是以每 16 位作为一组，每组用冒号 「:」 隔开。如果出现连续的 0 时还可以将这些 0 省略，并用两个冒号 「::」隔开。但是，一个 IP 地址中只允许出现一次两个连续的冒号。

优点

• IPv6 可自动配置，可以实现自动分配IP地址。
• IPv6 包头包首部长度采用固定的值 40 字节，去掉了包头校验和，简化了首部结构，减轻了路由器负荷，大大提高了传输的性能。
• IPv6 有应对伪造 IP 地址的网络安全功能以及防止线路窃听的功能，大大提升了安全性。

IP分片&重组

MTU概述

IP数据报在互联网上传输时，要经过多个物理网络才能抵达目的端。然而不同的网络由于链路层和介质的物理特性不一样，传输时对接收的数据帧的最大长度有不同的限制，这个限制称为最大存储单元MTU。如果我们发的数据帧大于MTU，就要进行分片处理。

具体的分片与重组

分片：分片时，在每个数据报片的首部，存放该数据报的标识、标志位和片偏移。

重组：重组时，标识用来分辨该数据报片的原数据报是哪个；标志位中的MF用来分辨这是不是原数据报的最后一片；片偏移用来分辨这个数据报片相对原数据报的位置。

通过这几个字段，可以稳定的完成数据报的分片与重组操作。

IP地址和路由控制

IP地址与路由控制

IP地址的网络地址部分是用来进行路由控制的。

路由控制表 中记录着网络地址与下一步应该发送至路由器的地址，在主机和路由器上都会有各自的路由器控制表。

在发送IP包时，首先要确定 IP包 的目标地址，再从路由表中找到与该地址 具有相同网络地址 的记录，根据该记录将IP包转发给相应的下一个路由器。如果路由控制表中存在多条相同的网络地址记录，就选择相同位数最多的网络地址，也就是最长匹配。

环回地址

环回地址是不会流向网络的，环回地址是在同一台计算机上的程序之间通信所使用的一个默认地址。

计算机使用一个特殊的IP地址127.0.0.1作为环回地址。与该地址具有相同意义的是一个叫做localhost的主机名，使用这个IP或主机名时，数据包不会流向网络。

ARP

ARP

在传输一个 IP 数据报的时候，确定了源 IP 地址和目标 IP 地址后，就会通过主机「路由表」确定 IP 数据包下一跳。然而，网络层的下一层是数据链路层，所以我们还要知道「下一跳」的 MAC 地址。

由于主机的路由表中可以找到下一条的 IP 地址，所以可以通过 ARP 协议，求得下一跳的 MAC 地址。

ARP 如何知道对方 MAC 地址

ARP 是借助 ARP 请求与 ARP 响应两种类型的包确定 MAC 地址的。

• 主机会通过广播发送 ARP 请求，这个包中包含了想要知道的 MAC 地址的主机 IP 地址。
• 当同个链路中的所有设备收到 ARP 请求时，会去拆开 ARP 请求包里的内容，如果 ARP 请求包中的目标 IP 地址与自己的 IP 地址一致，那么这个设备就将自己的 MAC 地址塞入 ARP 响应包返回给主机。

NAT

https://blog.csdn.net/s2603898260/article/details/118755474

https://zhuanlan.zhihu.com/p/86759357

NAT

一种网络地址转换 NAT 的方法，缓解了 IPv4 地址耗尽的问题。

简单的来说 NAT 就是在同个公司、家庭、教室内的主机对外部通信时，把私有 IP 地址转换成公有 IP 地址。

NAT不仅能解决IP地址不足的问题，而且还能够有效地避免来自网络外部的攻击，隐藏并保护网络内部的计算机。

如果由N个私有IP地址，就要有N个公有IP地址。这怎么就缓解了 IPv4 地址耗尽的问题？

确实是，普通的 NAT 转换没什么意义。

由于绝大多数的网络应用都是使用传输层协议 TCP 或 UDP 来传输数据的。因此，可以把 IP 地址 + 端口号一起进行转换。这样，就用一个全球 IP 地址就可以了，这种转换技术就叫网络地址与端口转换 NAPT。

图中有两个客户端 192.168.1.10 和 192.168.1.11 同时与服务器 183.232.231.172 进行通信，并且这两个客户端的本地端口都是 1025。

此时，两个私有 IP 地址都转换 IP 地址为公有地址 120.229.175.121，但是以不同的端口号作为区分。

于是，生成一个 NAPT 路由器的转换表，就可以正确地转换地址跟端口的组合，令客户端 A、B 能同时与服务器之间进行通信。

这种转换表在 NAT 路由器上自动生成。例如，在 TCP 的情况下，建立 TCP 连接首次握手时的 SYN 包一经发出，就会生成这个表。而后又随着收到关闭连接时发出 FIN 包的确认应答从表中被删除。

NAT的缺点

当然有缺陷，肯定没有十全十美的方案。

由于 NAT/NAPT 都依赖于自己的转换表，因此会有以下的问题：

• 外部无法主动与 NAT 内部服务器建立连接，因为 NAPT 转换表没有转换记录。
• 转换表的生产与转换操作都会产生性能开销。
• 通信过程中，如果 NAT 路由器重启了，所有的 TCP 连接都将被重置。

如何解决 NAT 潜在的问题呢？

解决的方法主要两种方法。

第一种就是改用 IPv6

IPv6 可用范围非常大，以至于每台设备都可以配置一个公有 IP 地址，就不搞那么多花里胡哨的地址转换了，但是 IPv6 普及速度还需要一些时间。

第二种 NAT 穿透技术

NAT 穿越技术拥有这样的功能，它能够让网络应用程序主动发现自己位于 NAT 设备之后，并且会主动获得 NAT 设备的公有 IP，并为自己建立端口映射条目，注意这些都是 NAT设备后的应用程序自动完成的。

也就是说，在 NAT 穿越技术中，NAT 设备后的应用程序处于主动地位，它已经明确地知道 NAT 设备要修改它外发的数据包，于是它主动配合 NAT 设备的操作，主动地建立好映射，这样就不像以前由 NAT 设备来建立映射了。

总结来说，就是客户端主动从 NAT 设备获取公有 IP 地址，然后自己建立端口映射条目，然后用这个条目对外通信，就不需要 NAT 设备来进行转换了。

ICMP

ICMP（Internet Control Message Protocol）Internet控制报文协议。它是TCP/IP协议簇的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。

ICMP协议是一种面向无连接的协议，用于传输出错报告控制信息。它是一个非常重要的协议，它对于网络安全具有极其重要的意义。 [3它属于网络层协议，主要用于在主机与路由器之间传递控制信息，包括报告错误、交换受限控制和状态信息等。当遇到IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况时，会自动发送ICMP消息。

ICMP 是 TCP/IP 模型中网络层的重要成员，与 IP 协议、ARP 协议、RARP 协议及 IGMP 协议共同构成 TCP/IP 模型中的网络层。ping 和 tracert是两个常用网络管理命令，ping 用来测试网络可达性，tracert 用来显示到达目的主机的路径。ping和 tracert 都利用 ICMP 协议来实现网络功能，它们是把网络协议应用到日常网络管理的典型实例。

从技术角度来说，ICMP就是一个“错误侦测与回报机制”，其目的就是让我们能够检测网路的连线状况﹐也能确保连线的准确性。当路由器在处理一个数据包的过程中发生了意外，可以通过ICMP向数据包的源端报告有关事件。

其功能主要有：侦测远端主机是否存在，建立及维护路由资料，重导资料传送路径（ICMP重定向），资料流量控制。ICMP在沟通之中，主要是透过不同的类别(Type)与代码(Code) 让机器来识别不同的连线状况。

ICMP 是个非常有用的协议﹐尤其是当我们要对网路连接状况进行判断的时候。

RARP

ARP 协议是已知 IP 地址 求 MAC 地址，那 RARP 协议正好相反。

它是已知 MAC 地址求 IP 地址。例如将打印机服务器等小型嵌入式设备接入到网络时就经常会用得到。

通常这需要架设一台 RARP 服务器，在这个服务器上注册设备的 MAC 地址及其 IP 地址。然后再将这个设备接入到网络，接着：

• 该设备会发送一条「我的 MAC 地址是XXXX，请告诉我，我的IP地址应该是什么」的请求信息。
• RARP 服务器接到这个消息后返回「MAC地址为 XXXX 的设备，IP地址为 XXXX」的信息给这个设备。

最后，设备就根据从 RARP 服务器所收到的应答信息设置自己的 IP 地址。