计算机网络

博主： MingZe
发布时间：2022 年 10 月 10 日
825次浏览
暂无评论
35850字数
分类：教程基础知识

TCP、HTTP、HTTPS、IP好好学！！！

右侧有目录

网络模型

OSI网络模型

应用层：负责给应用程序提供统一的接口
表示层：负责把数据格式转换成另一个系统能识别的格式
会话层：负责建立、管理和终止表示层之间的通话链接
传输层：负责端到端的数据传输
网络层：负责数据的路由、转发、分片
数据链路层：负责数据的封帧和差错监测，以及MAC寻址
物理层：负责在物理网络中的传输

TCP/IP网络模型

应用层

负责向用户提供一组应用程序

电脑或手机使用的应用软件都在应用层实现。应用层只需要专注于为用户提供应用功能，比如 HTTP、FTP、Telnet、DNS、SMTP等。

应用层是工作在操作系统中的用户态，传输层及以下则工作在内核态

传输层

负责端到端的通信

应用层的数据包会传给传输层，传输层是为应用层提供网络支持的。

在传输层会有两个传输协议，分别是 TCP 和 UDP。

TCP 的全称叫传输控制协议

TCP 相比 UDP 多了很多特性，比如流量控制、超时重传、拥塞控制等，这些都是为了保证数据包能可靠地传输给对方。

UDP 相对来说就很简单，简单到只负责发送数据包，不保证数据包是否能抵达对方，但它实时性相对更好，传输效率也高。

应用需要传输的数据可能会非常大，如果直接传输就不好控制，因此当传输层的数据包大小超过 MSS（TCP 最大报文段长度），就要将数据包分块，这样即使中途有一个分块丢失或损坏了，只需要重新发送这一个分块，而不用重新发送整个数据包。在 TCP 协议中，我们把每个分块称为一个 TCP 段

当设备作为接收方时，传输层则要负责把数据包传给应用，但是一台设备上可能会有很多应用在接收或者传输数据，因此需要用一个编号将应用区分开来，这个编号就是端口。

网络层

负责网络包的封装、分片、路由、转发

实际的传输功能就交给下一层，也就是网络层

网络层最常使用的是 IP 协议，IP 协议会将传输层的报文作为数据部分，再加上 IP 包头组装成 IP 报文，如果 IP 报文大小超过 MTU（以太网中一般为 1500 字节）就会再次进行分片，得到一个即将发送到网络的 IP 报文。

用 IP 地址给设备进行编号，对于 IPv4 协议， IP 地址共 32 位，分成了四段（比如，192.168.100.1），每段是 8 位。

IP 地址分成两种意义：

一个是网络号，负责标识该 IP 地址是属于哪个「子网」的；
一个是主机号，负责标识同一「子网」下的不同主机；

需要配合子网掩码才能算出 IP 地址的网络号和主机号。

10.100.122.0/24，后面的/24表示就是 255.255.255.0 子网掩码，255.255.255.0 二进制是「11111111-11111111-11111111-00000000」

/xx 说的都是子网的网络号，实际的 C 类还是24位

24 代表 24 位子网网络号，子网掩码用全 1 表示。

怎么计算出网络地址和主机地址呢？

将 10.100.122.2 和 255.255.255.0 进行按位与运算，就可以得到网络号，

将 255.255.255.0 取反后与IP地址进行进行按位与运算，就可以得到主机号。

IP 协议还有另一个重要的能力就是路由。

实际场景中，两台设备并不是用一条网线连接起来的，而是通过很多网关、路由器、交换机等众多网络设备连接起来的，那么就会形成很多条网络的路径，因此当数据包到达一个网络节点，就需要通过路由算法决定下一步走哪条路径。

路由器寻址工作中，就是要找到目标地址的子网，找到后进而把数据包转发给对应的网络内。

IP 协议的寻址作用是告诉我们去往下一个目的地该朝哪个方向走，路由则是根据「下一个目的地」选择路径。

网络接口层

负责在网络包在物理网络中的传输，比如网络包的封帧、MAC寻址、差错监测以及网卡传输网络帧

网络接口层在 IP 头部的前面加上 MAC 头部，并封装成数据帧发送到网络上。

MAC 头部是以太网使用的头部，它包含了接收方和发送方的 MAC 地址等信息，我们可以通过 ARP 协议获取对方的 MAC 地址。

总结

综上所述，TCP/IP 网络通常是由上到下分成 4 层，分别是应用层，传输层，网络层和网络接口层。

网络接口层的传输单位是帧（frame），

IP 层的传输单位是包（packet），

TCP 层的传输单位是段（segment），

HTTP 的传输单位则是消息或报文（message）。

但这些名词并没有什么本质的区分，可以统称为数据包。

网页输入url经历了什么

1、解析url

首先浏览器做的第一步工作就是要对 URL 进行解析，从而生成发送给 Web 服务器的请求信息。

协议 + 域名/ip + 端口 + 文件路径

2、生成 HTTP请求

浏览器确定了 Web 服务器和文件名，接下来就是根据这些信息来生成 HTTP 请求消息了。

请求方法、url、版本

url 中只有域名，却不知道 ip 地址是多少

3、DNS查询地址

1、先到 hosts 文件看是否有缓存

2、在去本地DNS服务器

3、去根DNS服务器 (.) ，根DNS服务器发现是.com，则让你去顶级DNS服务器找(.com)

4、顶级域名服务器让你去权威DNS服务器，最后告诉你 ip 地址返回本地DNS

5、本地DNS将 ip 地址返回客户端

4、协议栈

通过 DNS 获取到 IP 后，就可以把 HTTP 的传输工作交给操作系统中的协议栈

浏览器通过调用 socket 库，来委托协议栈工作。

协议栈的上部分主要是收发数据的 TCP 和 UDP 协议。

下部分是 IP 协议将网络包发送给接收方。其中 IP 协议还包括 ICMP 和 ARP。

ICMP 用于告知网络包传送过程中产生的错误以及各种控制信息。
ARP 用于根据 IP 地址查询相应的以太网 MAC 地址。

IP 下面的网卡驱动程序负责控制网卡硬件，最下面的网卡是负责完成对网线中的信号收发操作。

5、TCP 可靠传输

TCP报文头部

源端口号、目的端口号

序号（包乱序）

确认号（目的是确认发出去对方是否有收到）

状态位（SYN 是发起一个连接，ACK 是回复，RST 是重新连接，FIN 是结束连接等）

窗口大小（TCP 要做流量控制）

拥塞控制

在 HTTP 传输数据之前，首先需要 TCP 建立连接，TCP 连接的建立，通常称为三次握手。

一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。
然后客户端主动发起连接 SYN，之后处于 SYN-SENT 状态。
服务端收到发起的连接，返回 SYN，并且 ACK ，之后处于 SYN-RCVD 状态。
客户端收到服务端发送的 SYN 和 ACK 之后，发送对 SYN 确认的 ACK，之后处于 ESTABLISHED 状态，因为它一发一收成功了。
服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态，因为它也一发一收了。

所以三次握手目的是保证双方都有发送和接收的能力。

在双方建立了连接后，TCP 报文中的数据部分就是存放 HTTP 头部 + 数据，组装好 TCP 报文之后，就需交给下面的网络层处理。

6、远程定位IP

将数据封装成网络包发送给通信对象。

在 IP 协议里面需要有源地址 IP 和 目标地址 IP：

源地址IP，即是客户端输出的 IP 地址；
目标地址，即通过 DNS 域名解析得到的 Web 服务器 IP。

网络包的报文： ip头部 + TCP头部 + HTTP 头部 + 数据

7、两点传输 MAC

生成了 IP 头部之后，接下来网络包还需要在 IP 头部的前面加上 MAC 头部。在 MAC 包头里需要发送方 MAC 地址和接收方目标 MAC 地址，用于两点之间的传输。

发送方的 MAC 地址是从网卡中读出来的，接收方的 MAC 地址需要查路由表中的mac地址，可以用过 ARP 协议找到MAC地址

8、出口

网络包只是存放在内存中的一串二进制数字信息，没有办法直接发送给对方。因此，我们需要将数字信息转换为电信号，才能在网线上传输，负责执行这一操作的是网卡，要控制网卡还需要靠网卡驱动程序。网卡驱动获取网络包之后，会将其复制到网卡内的缓存区中，接着会在其开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列。

起始帧分界符是一个用来表示包起始位置的标记
末尾的 FCS（帧校验序列）用来检查包传输过程是否有损坏

最后网卡会将包转为电信号，通过网线发送出去。

9、送别者—交换机

交换机工作在 MAC 层，也称为二层网络设备。

首先，电信号到达网线接口，交换机里的模块进行接收，接下来交换机里的模块将电信号转换为数字信号。然后通过包末尾的 FCS 校验错误，如果没问题则放到缓冲区。接下来需要查询一下这个包的接收方 MAC 地址是否已经在 MAC 地址表中有记录了。交换机根据 MAC 地址表查找 MAC 地址，然后将信号发送到相应的端口。

交换机不具有MAC地址

10、出境大门—路由器

网络包经过交换机之后，现在到达了路由器，并在此被转发到下一个路由器或目标设备。

因为路由器是基于 IP 设计的，俗称三层网络设备，路由器的各个端口都具有 MAC 地址和 IP 地址；
而交换机是基于以太网设计的，俗称二层网络设备，交换机的端口不具有 MAC 地址。

当转发包时，首先路由器端口会接收发给自己的以太网包，然后路由表查询转发目标，再由相应的端口作为发送方将以太网包发送出去。

（首先，电信号到达网线接口部分，路由器中的模块会将电信号转成数字信号，然后通过包末尾的 FCS 进行错误校验。如果没问题则检查 MAC 头部中的接收方 MAC 地址，看看是不是发给自己的包，如果是就放到接收缓冲区中，否则就丢弃这个包。）

完成包接收操作之后，路由器就会去掉包开头的 MAC 头部。

MAC 头部的作用就是将包送达路由器，其中的接收方 MAC 地址就是路由器端口的 MAC 地址。因此，当包到达路由器之后，MAC 头部的任务就完成了，于是 MAC 头部就会被丢弃。

接下来，路由器会根据 MAC 头部后方的 IP 头部中的内容进行包的转发操作。

（接下来就会进入包的发送操作。首先，我们需要根据路由表的网关列判断对方的地址)

如果网关是一个 IP 地址，则这个IP 地址就是我们要转发到的目标地址，还未抵达终点，还需继续需要路由器转发。
如果网关为空，则 IP 头部中的接收方 IP 地址就是要转发到的目标地址，也是就终于找到 IP 包头里的目标地址了，说明已抵达终点。

源 IP 和目标 IP 始终是不会变的，一直变化的是 MAC 地址，因为需要 MAC 地址在以太网内进行两个设备之间的包传输。

11、互相扒皮

服务器会先扒开数据包的 MAC 头部，查看是否和服务器自己的 MAC 地址符合，符合就将包收起来。

接着继续扒开数据包的 IP 头，发现 IP 地址符合，根据 IP 头中协议项，知道自己上层是 TCP 协议。

扒开 TCP 的头，里面有序列号，需要看一看这个序列包是不是我想要的，如果是就放入缓存中然后返回一个 ACK，如果不是就丢弃。TCP头部里面还有端口号， HTTP 的服务器正在监听这个端口号。

服务器自然就知道是 HTTP 进程想要这个包，于是就将包发给 HTTP 进程。

务器的 HTTP 进程看到，原来这个请求是要访问一个页面，于是就把这个网页封装在 HTTP 响应报文里。

HTTP 响应报文也需要穿上 TCP、IP、MAC 头部，

穿好头部衣服后，从网卡出去，交由交换机转发到路由器，路由器就把响应数据包发到了下一个路由器，就这样跳啊跳。再由交换机转发到客户端。客户端开始扒皮，把收到的数据包的皮扒剩 HTTP 响应报文后，交给浏览器去渲染页面，一份特别的数据包快递，就这样显示出来了！

向服务器发起了 TCP 四次挥手，至此双方的连接就断开了。

背诵篇

1、首先浏览器第一步工作就是解析url，生成http请求。
2、生成http请求前，先用DNS查询ip地址。先查询自己的hosts文件看是否存在，不存在去本地的DNS服务器查，不存在就去根DNS服务器，根告诉我去顶级DNS服务器找，顶级告诉我去权威DNS服务器，权威查询出我的ip地址，返回到本地DNS服务器，本地将ip返回给客户端。
3、DNS获取ip后，传输http的动作交给操作系统的协议栈。浏览器通过调用socket库，来委托协议栈工作。协议栈主要分为两部分，上部分是负责收发数据的TCP和UDP，下部分是IP协议将网络包发送给接收方，还有ICMP和ARP协议。ICMP是用来检验网络包传输过程中产生的错误以及各种控制信息，ARP用来查询以太网的MAC地址。IP下面的网卡驱动程序负责控制网卡，网卡负责对网线中的信号收发操作。
4、在HTTP传输数据前，首先需要TCP建立连接，通称为三次握手（介绍三次握手）目的是为了双方都有发送和接收的能力。建立链接后，TCP报文存放：HTTP头部 + 数据，发给网络层处理。
5、网络层接收到数据封装网络包发送给通信对象。网络包报文存放：ip头部 + TCP 头部 + HTTP 头部 + 数据。网络层ip协议中需要有原地址IP和目标地址IP。
6、知道目的地后但因路程遥远不知从何去向，所以还要在ip头部加上MAC地址。在mac包头需要发送方mac地址（网卡读到）和接收方的mac地址（路由表中的mac地址，通过ARP协议找），用于两点之间传输。
7、网络包只是存放在内存中的二进制信息，没有办法传给对方。所以我们需要将数字信息转换为电信号，就需要网卡，控制网卡还需要靠网卡驱动程序，网卡驱动获取网络包后复制到网卡的缓存中，并在开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列。最后网卡将包换为电信号，通过网线发送出去。
8、电信号到达交换机，交换机将电信号转换为数字信号，通过FCS（帧校验序列）校验没问题放到缓冲区，接着查询这个包的的接收方MAC地址。交换机根据MAC地址表查询MAC地址，然后将信号发送给相应的端口。（交换机是没有MAC地址的）
9、网络包经过交换机后，到达了路由器。通过FCS（帧校验序列）没问题就检查MAC头部看是不是发给自己的包。完成包接收操作之后，路由器就会去掉包开头的 MAC 头部。接下来，路由器会根据 MAC 头部后方的 IP 头部中的内容查询路由表判断转发目标，进行包的转发操作。
10、服务器收到网络包后，先看MAC头部查看是否是发送给自己的，然后检查IP头部，然后检查TCP头部，里面有序列化号，序列号符合就放入缓存返回一个ACK，不是就丢弃。TCP头部中还有端口号，看是哪个进程需要处理。例如服务器的 HTTP 进程看到，原来这个请求是要访问一个页面，于是就把这个网页封装在 HTTP 响应报文里。HTTP 响应报文也需要穿上 TCP、IP、MAC 头部。封好头部，从网卡出去，交由交换机转发到路由器，路由器就把响应数据包发到了下一个路由器，就这样找到客户端。收到的数据包的一层层解析到HTTP 响应报文后，交给浏览器去渲染页面就这样显示出来了。最后，客户端要离开了，向服务器发起了 TCP 四次挥手，至此双方的连接就断开了

TCP(字节流)

TCP头部格式

序列号

在建立连接时由计算机生成的随机数作为初始值，通过SYN包传给接收端，每发送一次就累加一次该数据字节数的大小。用来解决网络包乱序问题

确认应答号

下一次期待收到的数据的序列号，发送端收到这个确认应答以后可以认为之前发送的数据被正常接收。用来解决丢包的问题

控制位：

ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。
RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

TCP是什么

TCP是面向链接、可靠性、基于字节流的传输层通讯协议

面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法读出一个有效的用户消息的。并且 TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。（TCP不像UDP一样，一个报文表示一个消息，一个消息可能在多个报文中）

边界：

固定长度的消息；
特殊字符作为边界；
自定义消息结构。

TCP链接

用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括Socket、序列号和窗口大小称为连接。

建立一个 TCP 连接是需要客户端与服务器端达成上述三个信息的共识。

Socket：由 IP 地址和端口号组成
序列号：用来解决乱序问题等
窗口大小：用来做流量控制

如何唯一确定一个 TCP 连接呢？

源地址
源端口
目的地址
目的端口

TCP 连接是由四元组（源IP地址，源端口，目的IP地址，目的端口）唯一确认的，那么只要四元组中其中一个元素发生了变化，那么就表示不同的 TCP 连接的。

有一个 IP 的服务器监听了一个端口，它的 TCP 的最大连接数是多少？

服务器通常固定在某个本地端口上监听，等待客户端的连接请求。

最大TCP连接数 = 客户端的IP数 * 客户端的端口数

对 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数，约为 2 的 48 次方。

UDP

UDP 不提供复杂的控制机制，利用 IP 提供面向无连接、不可靠的通信服务。

头部只有 8 个字节

TCP与UDP

tcp三个特点、首部-> 拥塞控制流量控制首部长度、一对一一对多、可靠性

1、连接

TCP 是面向连接，传输数据前先要建立连接。
UDP 是不需要连接，即刻传输数据。

2、服务对象

TCP 是一对一的两点服务。
UDP 支持一对一、一对多、多对多的交互通信。

3、可靠性

TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
UDP 是尽最大努力交付，不保证可靠交付数据。

4、传输方式

TCP 是流式传输，没有边界，但保证顺序和可靠。
UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

5、拥塞控制、流量控制

TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

6、首部长度

TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。
UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

7、分片不同

TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP 数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层。

三次握手

1、客户端和服务端都处于 closed 状态，先是服务端主动监听某个端口，处于 listen 状态。客户端会随机初始化序号 client_isn 将此序号置于 TCP 首部的序号字段中，同时把 SYN 标志位置为 1，表示 SYN报文。接着把 SYN报文发送给服务端，表示向服务端发起连接，然后客户端处于 syn-sent状态。

2、服务器收到客户端的 SYN报文后，服务端也初始化自己的序号 server_isn 。将此序号填入TCP首部的序号字段中，其次把TCP首部的确认应答号字段填入 client_isn + 1，接着把 SYN 和 ACK 的标志位置为 1。最后把报文发给客户端。然后服务端处于 syn-rcvd

3、客户端收到服务端报文后，还要向服务端回应一个应答报文，先将应答报文TCP首部 ACK标志位置为1，其次确认应答号填入 server_isn + 1，最后把报文发送给服务端，这次报文可以携带数据，客户端处于 established状态。服务端收到客户端的应答报文后，也进入 established状态。

第三次握手是可以携带数据的，前两次握手是不可以携带数据的

如何在 Linux 系统中查看 TCP 状态？

netstat -napt

为什么不是两次四次

TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。

防止历史连接的建立
客户端向服务端发送 seq=90，然后客户端宕机并且网络阻塞，服务器没收到，客户端又发送 seq num=100。网络恢复，服务端一定先收到 seq num=90，返回客户端 ack num=91。但客户端希望收到101。于是发给服务端一个拒绝链接(RST)。两次握手就没法实现了。两次握手，当服务端向客户端返回ack num时就已经建立连接可以发送数据，浪费了资源。

同步双方初始序列号
序列号能够保证数据包不重复、不丢弃和按序传输。一来一回的握手能够保证双方的初始序列号能被可靠的同步

不使用「两次握手」和「四次握手」的原因：

「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
「四次握手」：三次握手就已经理论上最少可靠连接建立，第二三次合并成一次，就变成三次握手了。

MTU MSS

MTU最大传输单元：一个网络包的最大长度，以太网中一般为 1500 字节；
MSS最大报文大小：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度；

当 IP 层有一个超过 MTU 大小的数据（TCP 头部 + TCP 数据）要发送，那么 IP 层就要进行分片，把数据分片成若干片，保证每一个分片都小于 MTU。把一份 IP 数据报进行分片以后，由目标主机的 IP 层来进行重新组装后，再交给上一层 TCP 传输层。

这看起来井然有序，但这存在隐患的，那么当如果一个 IP 分片丢失，整个 IP 报文的所有分片都得重传。

因为 IP 层本身没有超时重传机制，它由传输层的 TCP 来负责超时和重传。

当接收方发现 TCP 报文（头部 + 数据）的某一片丢失后，则不会响应 ACK 给对方，那么发送方的 TCP 在超时后，就会重发「整个 TCP 报文（头部 + 数据）」。

因此，可以得知由 IP 层进行分片传输，是非常没有效率的。

所以，为了达到最佳的传输效能 TCP 协议在建立连接的时候通常要协商双方的 MSS 值，当 TCP 层发现数据超过 MSS 时，则就先会进行分片，当然由它形成的 IP 包的长度也就不会大于 MTU ，自然也就不用 IP 分片了。

经过 TCP 层分片后，如果一个 TCP 分片丢失后，进行重发时也是以 MSS 为单位，而不用重传所有的分片，大大增加了重传的效率。

第一次握手丢失

如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发「超时重传」机制，重传 SYN 报文。

重发的次数由 tcp_syn_retries 参数控制，默认是 5 次：

通常，第一次超时重传是在 1 秒后，第二次超时重传是在 2 秒，第三次超时重传是在 4 秒后，第四次超时重传是在 8 秒后，第五次是在超时重传 16 秒后。没错，每次超时的时间是上一次的 2 倍。

第二次握手丢失

客户端就会触发超时重传机制，重传 SYN 报文。

服务端这边会触发超时重传机制，重传 SYN-ACK 报文。

容易SYN攻击通过调节参数来控制半连接队列

第三次握手丢失

ACK 报文是不会有重传的，当 ACK 丢失了，就由对方重传对应的报文。

SYN 攻击

假设攻击者短时间伪造不同 IP 地址的 SYN 报文，服务端每接收到一个 SYN 报文，就进入SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报文，无法得到未知 IP 主机的 ACK 应答，久而久之就会占满服务端的半连接队列，使得服务器不能为正常用户服务。

解决

1、修改参数

通过修改 Linux 内核参数，控制队列大小和当队列满时应做什么处理。

当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。控制该队列的最大值如下参数：

net.core.netdev_max_backlog

SYN_RCVD 状态连接的最大个数：

net.ipv4.tcp_max_syn_backlog

超出处理能时，对新的 SYN 直接回报 RST，丢弃连接：

net.ipv4.tcp_abort_on_overflow

2、cookie

正常流程：

当服务端接收到客户端的 SYN 报文时，会将其加入到内核的「 SYN 队列」；
接着发送 SYN + ACK 给客户端，等待客户端回应 ACK 报文；
服务端接收到 ACK 报文后，从「 SYN 队列」移除放入到「 Accept 队列」；
应用通过调用 accpet() socket 接口，从「 Accept 队列」取出连接。

受到 SYN 攻击：

如果不断受到 SYN 攻击，就会导致 SYN 队列（半连接队列）被占满，从而导致无法在建立新的连接。

tcp_syncookies 的方式可以应对 SYN 攻击的方法：

net.ipv4.tcp_syncookies = 1

当「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」；
计算出一个 cookie 值，再以 SYN + ACK 中的「序列号」返回客户端，
服务端接收到客户端的应答报文时，服务器会检查这个 ACK 包的合法性。如果合法，直接放入到「 Accept 队列」。
最后应用通过调用 accpet() socket 接口，从「 Accept 队列」取出的连接。

四次挥手

双方都可发起断开链接

1、客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。

2、服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。

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

4、客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态。服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。

客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。

每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。
主动关闭连接的，才有 TIME_WAIT 状态。

为什么是四次

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

第一次挥手丢失

收不到对方的ACK就会触发超时重传机制

第二次挥手丢失

ACK不会重传，还是重传FIN报文

第三次挥手丢失

重传FIN报文

第四次挥手丢失

重传FIN报文

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

如果第四次挥手的报文丢失，服务端没收到确认 ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。

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

为什么需要 TIME_WAIT 状态？

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。

需要 TIME-WAIT 状态，主要是两个原因：

防止历史连接中的数据，被后面相同四元组的连接错误的接收；
等待足够的时间以确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。

重传机制

报文丢失解决的方法

TCP 实现可靠传输的方式之一，是通过序列号与确认应答。

在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息

超时重传

重传机制的其中一个方式，就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据，也就是我们常说的超时重传。

TCP 会在以下两种情况发生超时重传：

数据包丢失
确认应答丢失

快速重传

TCP 还有另外一种快速重传（Fast Retransmit）机制，它不以时间为驱动，而是以数据驱动重传。

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

SACK

还有一种实现重传机制的方式叫：SACK（ Selective Acknowledgment）， 选择性确认。

这种方式需要在 TCP 头部「选项」字段里加一个 SACK 的东西，它可以将已收到的数据的信息发送给「发送方」，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

Duplicate SACK

Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。

滑动窗口

TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了，再发送下一个。但这种方式的缺点是效率比较低的。

窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。

窗口大小由哪一方决定？

TCP 头里有一个字段叫 Window，也就是窗口大小。

这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

所以，通常窗口的大小是由接收方的窗口大小来决定的。

发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。

流量控制

TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。

拥塞控制

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

所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。

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

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

其实只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。

拥塞控制有哪些控制算法？

拥塞控制主要是四个算法：

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

HTTP

概念

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。

请求报文(请求行/请求头/请求数据/空行)

请求行
求方法字段、URL字段和HTTP协议版本
例如：GET /index.html HTTP/1.1
请求头(key value形式)
User-Agent：产生请求的浏览器类型。
Accept：客户端可识别的内容类型列表。
Host：主机地址
请求数据
post方法中，会把数据以key value形式发送请求
空行
发送回车符和换行符，通知服务器以下不再有请求头

状态码

1xx

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx

3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

4xx

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

常见字段

Host 字段

客户端发送请求时，用来指定服务器的域名。

Host: www.A.com

Content-Length 字段

服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。

Content-Length: 1000

Connection 字段

Connection 字段最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。

HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。

Connection: keep-alive

一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。

Content-Type 字段

Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。

Content-Type: text/html; charset=utf-8

Content-Encoding 字段

Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

Content-Encoding: gzip

GET和POST区别

GET请求不安全，POST相对安全。GET参数通过URL传递，POST放在Request body中。抓包还是能看到请求体的内容，可以用HTTPS避免。
GET只接受 ASCII 字符，而POST没有限制。
GET请求在URL中传送的参数是有长度限制的，而POST没有。
GET请求会被浏览器主动cache，而POST不会。
GET主要是做获取操作，是幂等的，而POST主要是做修改删除增加，不是幂等的。

HTTP缓存

HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存

强制缓存

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存。

强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：

Cache-Control，是一个相对时间；
Expires，是一个绝对时间；

如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control的优先级高于 Expires 。

流程：

第一次请求服务器返回资源同时Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；

浏览器再次请求时会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期如果没有，则使用该缓存，否则重新请求服务器；

协商缓存

协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。

两种实现

第一种：请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段实现，这两个字段的意思是：

响应头部中的 Last-Modified：标示这个响应资源的最后修改时间；
请求头部中的 If-Modified-Since：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，去对比。没过期返回 304 走缓存，过期返回新资源 200

第二种：请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段

响应头部中 Etag：唯一标识响应资源；
请求头部中的 If-None-Match：当资源过期时，浏览器发现响应头里有 Etag，则再次向服务器发起请求时，会将请求头If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。

流程：

两种流程都一样，第一次访问服务器时，服务器响应头部加上 ETag 唯一标识。

当浏览器再次访问时，先检查 Cache-control是否过期，过期就请求头部加上 If-None-match / If-modified-since 去服务器比较，过期返回200，没过期返回304

Etag 的优先级大于 Last-Modified。
协商缓存这两个字段都需要配合强制缓存中 Cache-control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

HTTP1.1

优点

1、简单

HTTP报文格式就是 header + body，头部信息也是 key-value，易于理解。

2、灵活易扩展

HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。

HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。

HTTPS就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP3把TCP层换成了基于 UDP 的 QUIC

3、应用广泛

从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有跨平台的优越性。

缺点

1、无状态

不用额外的资源去记录状态信息，减轻服务器的负担；没有记忆能力，有关联性操作就会很麻烦

利用 Cookie在请求和响应报文中写入 Cookie 信息来控制客户端状态

2、明文传输不安全

get请求在URL中就能看到，post可以利用抓包。信息裸奔不安全

性能

1、长链接

早期 HTTP/1.0 是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求。HTTP/1.1 提出了长连接的通信方式，也叫持久连接

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

2、管道网络传输

在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

服务器必须按照接收请求的顺序发送对这些管道化请求的响应。
实际上 HTTP/1.1 管道化技术不是默认开启，而且浏览器基本都没有支持，所以后面讨论HTTP/1.1 都是建立在没有使用管道化的前提。

3、队头阻塞

请求 - 应答 的模式加剧了 HTTP 的性能问题。

因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」，好比上班的路上塞车。

优化

1、通过缓存技术避免发送HTTP请求

2、减少重定向请求次数(代理服务器)

3、合并请求减少TCP连接次数，握手时间

4、延迟发送请求(用户滑动在继续请求）

5、压缩(gzip无损压缩、WebP有损压缩)

HTTP1.1比HTTP1.0提高了什么

长链接改善了1.0短连接造成的性能开销
支持管道网络传输，只要第一个请求发出去不必等其回来就可以发送第二个请求

但HTTP1.1还是有性能瓶颈

请求/响应头部未经压缩就发送，首部信息越多延迟越大。只能压缩Body的部分
队头阻塞问题
没有请求优先级控制
请求只能从客户端开始，服务器只能被动响应

HTTP2

1、头部压缩

HTTP/2 会压缩头（Header），协议会帮你消除重复的部分。

HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

2、二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。增加了数据传输的效率。

3、数据流

流代表了一个完整的请求-响应数据交互过程。它具有如下几个特点：

双向性：同一个流内，可同时发送和接受数据。
有序性：流中被传输的数据就是二进制帧 。帧在流上的被发送与被接收都是按照顺序进行的。
并行性：流中的 二进制帧 都是被并行传输的，无需按顺序等待。但却不会引起数据混乱，因为每个帧都有顺序标号。它们最终会被按照顺序标号来合并。
流的创建：流可以被客户端或服务器单方面建立, 使用或共享。
流的关闭：流也可以被任意一方关闭。

客户端建立的 Stream ID必须是奇数号，而服务器建立的 Stream 必须是偶数号。

4、多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。

5、服务器推送

HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务端不再是被动地响应，可以主动向客户端发送消息。

HTTP/2 有什么缺陷？

HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。

HTTP3

HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后，才能处理下一个请求，这属于 HTTP 层队头阻塞。
HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC

1、无队头阻塞

当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。

2、更快的连接建立

HTTP/3 在传输数据前虽然需要 QUIC 协议握手，这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。

3、连接迁移

基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接，那么当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接。

而 QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

HTTP3的未来

QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题，因为有的网络设备是会丢掉 UDP 包的，而 QUIC 是基于UDP 实现的，那么如果网络设备无法识别这个是 QUIC 包，那么就会当作 UDP包，然后被丢弃。

HTTPS

定义

安全的超文本传输协议，使用传输层安全性(TLS)或安全套接字层(SSL)对通信协议进行加密。也就是 HTTP + SSL(TLS) = HTTPS。

区别

1、HTTP是超文本传输协议，是明文传输，有安全风险，HTTPS 加入了SSL/TLS安全协议，使得报文能够加密传输。

2、HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

3、HTTP端口是80，HTTPS的端口号是443

4、HTTPS需要向CA申请数字证书。

用途

加密
数据一致性
身份认证

解决

窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。

认识 SSL/TLS

TLS(Transport Layer Security) 是 SSL(Secure Socket Layer) 的后续版本，它们是用于在互联网两台计算机之间用于身份验证和加密的一种协议。

SSL 即安全套接字层，它在 OSI 七层网络模型中处于第五层，SSL 在 1999 年被 IETF(互联网工程组)更名为 TLS ，即传输安全层，直到现在，TLS 一共出现过三个版本，1.1、1.2 和 1.3 ，目前最广泛使用的是 1.2，所以接下来的探讨都是基于 TLS 1.2 的版本上的。

TLS 用于两个通信应用程序之间提供保密性和数据完整性。TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术

SSL 是一个独立的协议，不只有 HTTP 可以使用，其他应用层协议也可以使用，比如 SMTP(电子邮件协议)、Telnet(远程登录协议) 等都可以使用。

TLS 在根本上使用对称加密和 非对称加密 两种形式。

对称加密

定义

一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密

缺点

如何让双方都用同一个密钥进行数据加密，同时不被别人知道

非对称加密

定义

两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

流程

客户端需要向服务器发送一条数据，浏览器需要保障数据的安全性，加密流程如下：
某网站服务器拥有公钥A与对应的私钥A’
客户端请求服务器的公钥A，公钥A是公开的，可以明文传输
客户端使用公钥A进行加密，将加密的数据发送给服务器
服务器收到数据，使用私钥A`进行解密，拿到数据
反之，服务器向客户端发送数据也是同样的流程。

缺点

非对称加密算法在解决了双方交换密钥的问题，但非对称加密算法非常耗时，而对称加密快很多

非对称加密+对称加密

定义

用非对称加密完成对称加密的密钥交换，之后再用对称加密进行加密

流程

某网站拥有用于非对称加密的公钥A、私钥A’。
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

缺点

某网站有用于非对称加密的公钥A、私钥A’。
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
通过这一通操作，攻击者就知道服务器和浏览器之间的公钥了，这样，对称加密就形同虚设了。
为什么会发生这样的事？因为浏览器拿到公钥的时候，他无法确定这个公钥是服务器的。在传输过程中，公钥被篡改，一方用篡改后的公钥加密，非对称加密形同虚设。

数字证书

如何证明浏览器收到的公钥一定是该网站的公钥？这个时候，就要引入第三方机构了，也被称作CA机构。

定义

网站只需要向CA机构申领一份数字证书，这份证书里面，包括了网站的公钥，网站的域名和其他一些网站基本信息。

然后CA机构用自己的私钥对证书进行加密，同时生成一段密文，这段密码就叫做数字签名

生成

CA机构拥有非对称加密的私钥和公钥。
网站需要申请数字证书，只需将自己网站的数据给CA机构(网站公钥，网站域名等)
CA机构对证书明文数据进行hash。
对hash后的值用私钥加密，得到数字签名

检验

拿到证书，从证书中得到公钥，数字签名等数据。
用 CA 机构的公钥对数字签名解密（浏览器内置CA机构的公钥），得到S。
用 hash 算法对明文进行hash得到T。
所以此时比较 S 是否等于 T ，等于则表明证书可信。如果证书的数据没有被改动过, S 和 T 应该是相同的，则证书可信任，浏览器就用证书中的公钥加密数据。
如果S和T，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
数字签名是用 CA 机构的私钥加的密，只能用公钥来解密
证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了
一般浏览器会内置主流的CA机构的公钥

IP

认识

IP 在 TCP/IP 参考模型中处于第三层，也就是网络层。

网络层的主要作用是：实现主机与主机之间的通信，也叫点对点（end to end）通信。

网络层与数据链路层

IP 的作用是主机之间通信用的，而 MAC 的作用则是实现直连的两个设备之间通信，而 IP 则负责在没有直连的两个网络之间进行通信传输。

源IP地址和目标IP地址在传输过程中是不会变化的（前提：没有使用 NAT 网络），只有源 MAC 地址和目标 MAC 一直在变化

基础

IP 地址（IPv4 地址）由 32 位正整数来表示，IP 地址在计算机是以二进制的方式处理的。

IP 地址最大值：2的32次方

IP 地址并不是根据主机台数来配置的，而是以网卡。像服务器、路由器等设备都是有 2 个以上的网卡，也就是它们会有 2 个以上的 IP 地址。

无分类地址CIDR

正因为 IP 分类存在许多缺点，所以后面提出了无分类地址的方案，即 CIDR。

这种方式不再有分类地址的概念，32 比特的 IP 地址被划分为两部分，前面是网络号，后面是主机号。

表示形式 a.b.c.d/x，其中 /x 表示前 x 位属于网络号， x 的范围是 0 ~ 32，这就使得 IP 地址更加具有灵活性。

还有另一种划分网络号与主机号形式，那就是子网掩码，掩码的意思就是掩盖掉主机号，剩余的就是网络号。

将子网掩码和 IP 地址按位计算 AND，就可得到网络号。

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

因为两台计算机要通讯，首先要判断是否处于同一个广播域内，即网络地址是否相同。如果网络地址相同，表明接受方在本网络上，那么可以把数据包直接发送到目标主机。

路由器寻址工作中，也就是通过这样的方式来找到对应的网络号的，进而把数据包转发给对应的网络内。

怎么进行子网划分？

可以通过子网掩码划分出网络号和主机号，那实际上子网掩码还有一个作用，那就是划分子网。

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

未做子网划分的 ip 地址：网络地址＋主机地址
做子网划分后的 ip 地址：网络地址＋（子网网络地址＋子网主机地址）

假设对 C 类地址进行子网划分，网络地址 192.168.1.0，使用子网掩码 255.255.255.192 对其进行子网划分。

C 类地址中前 24 位是网络号，最后 8 位是主机号，根据子网掩码可知从 8 位主机号中借用 2 位作为子网号。

由于子网网络地址被划分成 2 位，那么子网地址就有 4 个，分别是 00、01、10、11，具体划分如下图：

公有 IP 地址与私有 IP 地址

私有 IP 地址通常是内部的 IT 人员管理，公有 IP 地址是由 ICANN 组织管理，中文叫「互联网名称与数字地址分配机构」。

公有 IP 地址是有个组织统一分配的，你就需要去申请购买一个公有 IP，这样全世界的人才能访问。并且公有 IP 地址基本上要在整个互联网范围内保持唯一。

IP 地址与路由控制

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

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

IP 分片与重组

我们最常见数据链路是以太网，它的 MTU 是 1500 字节。

那么当 IP 数据包大小大于 MTU 时， IP 数据包就会被分片。

经过分片之后的 IP 数据报在被重组的时候，只能由目标主机进行，路由器是不会进行重组的。

假设发送方发送一个 4000 字节的大数据报，若要传输在以太网链路，则需要把数据报分片成 3 个小数据报进行传输，再交由接收方重组成大数据报。

在分片传输中，一旦某个分片丢失，则会造成整个 IP 数据报作废，所以 TCP 引入了 MSS 也就是在 TCP 层进行分片不由 IP 层分片，那么对于 UDP 我们尽量不要发送一个大于 MTU 的数据报文

IPv6

IPv4 的地址是 32 位的，但是 IPv6 的地址是 128 位的

优点

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

标识

IPv4 地址长度共 32 位，是以每 8 位作为一组，并用点分十进制的表示方式。

IPv6 地址长度是 128 位，是以每 16 位作为一组，每组用冒号「:」隔开。

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

IPv6首部

取消了首部校验和字段。 因为在数据链路层和传输层都会校验，因此 IPv6 直接取消了 IP 的校验。
取消了分片/重新组装相关字段。 分片与重组是耗时的过程，IPv6 不允许在中间路由器进行分片与重组，这种操作只能在源与目标主机，这将大大提高了路由器转发的速度。
取消选项字段。 选项字段不再是标准 IP 首部的一部分了，但它并没有消失，而是可能出现在 IPv6 首部中的「下一个首部」指出的位置上。删除该选项字段使的 IPv6 的首部成为固定长度的 40 字节。

DNS

DNS 域名解析，DNS 可以将域名网址自动转换为具体的 IP 地址。

域名的层级关系

域名的层级关系类似一个树状结构：

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

域名解析的工作流程

看 浏览器上输入url经历了什么

ARP

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

ARP 又是如何知道对方 MAC 地址的呢？

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

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

操作系统通常会把第一次通过 ARP 获取的 MAC 地址缓存起来，以便下次直接从缓存中找到对应 IP 地址的 MAC 地址。

不过，MAC 地址的缓存是有一定期限的，超过这个期限，缓存的内容将被清除。

RARP

ARP 协议是已知 IP 地址求 MAC 地址，那 RARP 协议正好相反，它是已知 MAC 地址求 IP 地址。例如将打印机服务器等小型嵌入式设备接入到网络时就经常会用得到。

DHCP

通过 DHCP 动态获取 IP 地址，大大省去了配 IP 信息繁琐的过程。

NAT

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

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

由于绝大多数的网络应用都是使用传输层协议 TCP 或 UDP 来传输数据的。

因此，可以把 IP 地址 + 端口号一起进行转换。

这样，就用一个全球 IP 地址就可以了，这种转换技术就叫网络地址与端口转换 NAPT。

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

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

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

NAT 那么牛逼，难道就没缺点了吗？

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

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

ICMP

ICMP 全称是 Internet Control Message Protocol，也就是互联网控制报文协议。

功能

确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因和改善网络设置等。

在 IP 通信中如果某个 IP 包因为某种原因未能达到目标地址，那么这个具体的原因将由 ICMP 负责通知。

类型

ICMP 大致可以分为两大类：

一类是用于诊断的查询消息，也就是「查询报文类型」
另一类是通知出错原因的错误消息，也就是「差错报文类型」

IGMP

组播地址，也就是 D 类地址，既然是组播，那就说明是只有一组的主机能收到数据包，不在一组的主机不能收到数组包，怎么管理是否是在一组呢？那么，就需要 IGMP 协议了。

最后修改：2022 年 10 月 10 日 06 : 18 PM

赏杯咖啡喝谢谢您~

发表评论取消回复

评论 *

私密评论

名称 *

🎲

邮箱 *

地址

计算机网络

MingZe • 2022 年 10 月 10 日

TCP、HTTP、HTTPS、IP好好学！！！

右侧有目录

网络模型

OSI网络模型

应用层：负责给应用程序提供统一的接口
表示层：负责把数据格式转换成另一个系统能识别的格式
会话层：负责建立、管理和终止表示层之间的通话链接
传输层：负责端到端的数据传输
网络层：负责数据的路由、转发、分片
数据链路层：负责数据的封帧和差错监测，以及MAC寻址
物理层：负责在物理网络中的传输

TCP/IP网络模型

应用层

负责向用户提供一组应用程序

电脑或手机使用的应用软件都在应用层实现。应用层只需要专注于为用户提供应用功能，比如 HTTP、FTP、Telnet、DNS、SMTP等。

应用层是工作在操作系统中的用户态，传输层及以下则工作在内核态

传输层

负责端到端的通信

应用层的数据包会传给传输层，传输层是为应用层提供网络支持的。

在传输层会有两个传输协议，分别是 TCP 和 UDP。

TCP 的全称叫传输控制协议

TCP 相比 UDP 多了很多特性，比如流量控制、超时重传、拥塞控制等，这些都是为了保证数据包能可靠地传输给对方。

UDP 相对来说就很简单，简单到只负责发送数据包，不保证数据包是否能抵达对方，但它实时性相对更好，传输效率也高。

网络层

负责网络包的封装、分片、路由、转发

实际的传输功能就交给下一层，也就是网络层

用 IP 地址给设备进行编号，对于 IPv4 协议， IP 地址共 32 位，分成了四段（比如，192.168.100.1），每段是 8 位。

IP 地址分成两种意义：

一个是网络号，负责标识该 IP 地址是属于哪个「子网」的；
一个是主机号，负责标识同一「子网」下的不同主机；

需要配合子网掩码才能算出 IP 地址的网络号和主机号。

10.100.122.0/24，后面的/24表示就是 255.255.255.0 子网掩码，255.255.255.0 二进制是「11111111-11111111-11111111-00000000」

/xx 说的都是子网的网络号，实际的 C 类还是24位

24 代表 24 位子网网络号，子网掩码用全 1 表示。

怎么计算出网络地址和主机地址呢？

将 10.100.122.2 和 255.255.255.0 进行按位与运算，就可以得到网络号，

将 255.255.255.0 取反后与IP地址进行进行按位与运算，就可以得到主机号。

IP 协议还有另一个重要的能力就是路由。

路由器寻址工作中，就是要找到目标地址的子网，找到后进而把数据包转发给对应的网络内。

IP 协议的寻址作用是告诉我们去往下一个目的地该朝哪个方向走，路由则是根据「下一个目的地」选择路径。

网络接口层

负责在网络包在物理网络中的传输，比如网络包的封帧、MAC寻址、差错监测以及网卡传输网络帧

网络接口层在 IP 头部的前面加上 MAC 头部，并封装成数据帧发送到网络上。

MAC 头部是以太网使用的头部，它包含了接收方和发送方的 MAC 地址等信息，我们可以通过 ARP 协议获取对方的 MAC 地址。

总结

综上所述，TCP/IP 网络通常是由上到下分成 4 层，分别是应用层，传输层，网络层和网络接口层。

网络接口层的传输单位是帧（frame），

IP 层的传输单位是包（packet），

TCP 层的传输单位是段（segment），

HTTP 的传输单位则是消息或报文（message）。

但这些名词并没有什么本质的区分，可以统称为数据包。

网页输入url经历了什么

1、解析url

首先浏览器做的第一步工作就是要对 URL 进行解析，从而生成发送给 Web 服务器的请求信息。

协议 + 域名/ip + 端口 + 文件路径

2、生成 HTTP请求

浏览器确定了 Web 服务器和文件名，接下来就是根据这些信息来生成 HTTP 请求消息了。

请求方法、url、版本

url 中只有域名，却不知道 ip 地址是多少

3、DNS查询地址

1、先到 hosts 文件看是否有缓存

2、在去本地DNS服务器

3、去根DNS服务器 (.) ，根DNS服务器发现是.com，则让你去顶级DNS服务器找(.com)

4、顶级域名服务器让你去权威DNS服务器，最后告诉你 ip 地址返回本地DNS

5、本地DNS将 ip 地址返回客户端

4、协议栈

通过 DNS 获取到 IP 后，就可以把 HTTP 的传输工作交给操作系统中的协议栈

浏览器通过调用 socket 库，来委托协议栈工作。

协议栈的上部分主要是收发数据的 TCP 和 UDP 协议。

下部分是 IP 协议将网络包发送给接收方。其中 IP 协议还包括 ICMP 和 ARP。

ICMP 用于告知网络包传送过程中产生的错误以及各种控制信息。
ARP 用于根据 IP 地址查询相应的以太网 MAC 地址。

IP 下面的网卡驱动程序负责控制网卡硬件，最下面的网卡是负责完成对网线中的信号收发操作。

5、TCP 可靠传输

TCP报文头部

源端口号、目的端口号

序号（包乱序）

确认号（目的是确认发出去对方是否有收到）

状态位（SYN 是发起一个连接，ACK 是回复，RST 是重新连接，FIN 是结束连接等）

窗口大小（TCP 要做流量控制）

拥塞控制

在 HTTP 传输数据之前，首先需要 TCP 建立连接，TCP 连接的建立，通常称为三次握手。

一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。
然后客户端主动发起连接 SYN，之后处于 SYN-SENT 状态。
服务端收到发起的连接，返回 SYN，并且 ACK ，之后处于 SYN-RCVD 状态。
客户端收到服务端发送的 SYN 和 ACK 之后，发送对 SYN 确认的 ACK，之后处于 ESTABLISHED 状态，因为它一发一收成功了。
服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态，因为它也一发一收了。

所以三次握手目的是保证双方都有发送和接收的能力。

在双方建立了连接后，TCP 报文中的数据部分就是存放 HTTP 头部 + 数据，组装好 TCP 报文之后，就需交给下面的网络层处理。

6、远程定位IP

将数据封装成网络包发送给通信对象。

在 IP 协议里面需要有源地址 IP 和 目标地址 IP：

源地址IP，即是客户端输出的 IP 地址；
目标地址，即通过 DNS 域名解析得到的 Web 服务器 IP。

网络包的报文： ip头部 + TCP头部 + HTTP 头部 + 数据

7、两点传输 MAC

发送方的 MAC 地址是从网卡中读出来的，接收方的 MAC 地址需要查路由表中的mac地址，可以用过 ARP 协议找到MAC地址

8、出口

起始帧分界符是一个用来表示包起始位置的标记
末尾的 FCS（帧校验序列）用来检查包传输过程是否有损坏

最后网卡会将包转为电信号，通过网线发送出去。

9、送别者—交换机

交换机工作在 MAC 层，也称为二层网络设备。

交换机不具有MAC地址

10、出境大门—路由器

网络包经过交换机之后，现在到达了路由器，并在此被转发到下一个路由器或目标设备。

因为路由器是基于 IP 设计的，俗称三层网络设备，路由器的各个端口都具有 MAC 地址和 IP 地址；
而交换机是基于以太网设计的，俗称二层网络设备，交换机的端口不具有 MAC 地址。

当转发包时，首先路由器端口会接收发给自己的以太网包，然后路由表查询转发目标，再由相应的端口作为发送方将以太网包发送出去。

完成包接收操作之后，路由器就会去掉包开头的 MAC 头部。

接下来，路由器会根据 MAC 头部后方的 IP 头部中的内容进行包的转发操作。

（接下来就会进入包的发送操作。首先，我们需要根据路由表的网关列判断对方的地址)

如果网关是一个 IP 地址，则这个IP 地址就是我们要转发到的目标地址，还未抵达终点，还需继续需要路由器转发。
如果网关为空，则 IP 头部中的接收方 IP 地址就是要转发到的目标地址，也是就终于找到 IP 包头里的目标地址了，说明已抵达终点。

源 IP 和目标 IP 始终是不会变的，一直变化的是 MAC 地址，因为需要 MAC 地址在以太网内进行两个设备之间的包传输。

11、互相扒皮

服务器会先扒开数据包的 MAC 头部，查看是否和服务器自己的 MAC 地址符合，符合就将包收起来。

接着继续扒开数据包的 IP 头，发现 IP 地址符合，根据 IP 头中协议项，知道自己上层是 TCP 协议。

服务器自然就知道是 HTTP 进程想要这个包，于是就将包发给 HTTP 进程。

务器的 HTTP 进程看到，原来这个请求是要访问一个页面，于是就把这个网页封装在 HTTP 响应报文里。

HTTP 响应报文也需要穿上 TCP、IP、MAC 头部，

向服务器发起了 TCP 四次挥手，至此双方的连接就断开了。

背诵篇

1、首先浏览器第一步工作就是解析url，生成http请求。
2、生成http请求前，先用DNS查询ip地址。先查询自己的hosts文件看是否存在，不存在去本地的DNS服务器查，不存在就去根DNS服务器，根告诉我去顶级DNS服务器找，顶级告诉我去权威DNS服务器，权威查询出我的ip地址，返回到本地DNS服务器，本地将ip返回给客户端。
3、DNS获取ip后，传输http的动作交给操作系统的协议栈。浏览器通过调用socket库，来委托协议栈工作。协议栈主要分为两部分，上部分是负责收发数据的TCP和UDP，下部分是IP协议将网络包发送给接收方，还有ICMP和ARP协议。ICMP是用来检验网络包传输过程中产生的错误以及各种控制信息，ARP用来查询以太网的MAC地址。IP下面的网卡驱动程序负责控制网卡，网卡负责对网线中的信号收发操作。
4、在HTTP传输数据前，首先需要TCP建立连接，通称为三次握手（介绍三次握手）目的是为了双方都有发送和接收的能力。建立链接后，TCP报文存放：HTTP头部 + 数据，发给网络层处理。
5、网络层接收到数据封装网络包发送给通信对象。网络包报文存放：ip头部 + TCP 头部 + HTTP 头部 + 数据。网络层ip协议中需要有原地址IP和目标地址IP。
6、知道目的地后但因路程遥远不知从何去向，所以还要在ip头部加上MAC地址。在mac包头需要发送方mac地址（网卡读到）和接收方的mac地址（路由表中的mac地址，通过ARP协议找），用于两点之间传输。
7、网络包只是存放在内存中的二进制信息，没有办法传给对方。所以我们需要将数字信息转换为电信号，就需要网卡，控制网卡还需要靠网卡驱动程序，网卡驱动获取网络包后复制到网卡的缓存中，并在开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列。最后网卡将包换为电信号，通过网线发送出去。
8、电信号到达交换机，交换机将电信号转换为数字信号，通过FCS（帧校验序列）校验没问题放到缓冲区，接着查询这个包的的接收方MAC地址。交换机根据MAC地址表查询MAC地址，然后将信号发送给相应的端口。（交换机是没有MAC地址的）
9、网络包经过交换机后，到达了路由器。通过FCS（帧校验序列）没问题就检查MAC头部看是不是发给自己的包。完成包接收操作之后，路由器就会去掉包开头的 MAC 头部。接下来，路由器会根据 MAC 头部后方的 IP 头部中的内容查询路由表判断转发目标，进行包的转发操作。
10、服务器收到网络包后，先看MAC头部查看是否是发送给自己的，然后检查IP头部，然后检查TCP头部，里面有序列化号，序列号符合就放入缓存返回一个ACK，不是就丢弃。TCP头部中还有端口号，看是哪个进程需要处理。例如服务器的 HTTP 进程看到，原来这个请求是要访问一个页面，于是就把这个网页封装在 HTTP 响应报文里。HTTP 响应报文也需要穿上 TCP、IP、MAC 头部。封好头部，从网卡出去，交由交换机转发到路由器，路由器就把响应数据包发到了下一个路由器，就这样找到客户端。收到的数据包的一层层解析到HTTP 响应报文后，交给浏览器去渲染页面就这样显示出来了。最后，客户端要离开了，向服务器发起了 TCP 四次挥手，至此双方的连接就断开了

TCP(字节流)

TCP头部格式

序列号

在建立连接时由计算机生成的随机数作为初始值，通过SYN包传给接收端，每发送一次就累加一次该数据字节数的大小。用来解决网络包乱序问题

确认应答号

下一次期待收到的数据的序列号，发送端收到这个确认应答以后可以认为之前发送的数据被正常接收。用来解决丢包的问题

控制位：

ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建立连接时的 SYN 包之外该位必须设置为 1 。
RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
SYN：该位为 1 时，表示希望建立连接，并在其「序列号」的字段进行序列号初始值的设定。
FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。

TCP是什么

TCP是面向链接、可靠性、基于字节流的传输层通讯协议

面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法读出一个有效的用户消息的。并且 TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。（TCP不像UDP一样，一个报文表示一个消息，一个消息可能在多个报文中）

边界：

固定长度的消息；
特殊字符作为边界；
自定义消息结构。

TCP链接

用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括Socket、序列号和窗口大小称为连接。

建立一个 TCP 连接是需要客户端与服务器端达成上述三个信息的共识。

Socket：由 IP 地址和端口号组成
序列号：用来解决乱序问题等
窗口大小：用来做流量控制

如何唯一确定一个 TCP 连接呢？

源地址
源端口
目的地址
目的端口

有一个 IP 的服务器监听了一个端口，它的 TCP 的最大连接数是多少？

服务器通常固定在某个本地端口上监听，等待客户端的连接请求。

最大TCP连接数 = 客户端的IP数 * 客户端的端口数

对 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数，约为 2 的 48 次方。

UDP

UDP 不提供复杂的控制机制，利用 IP 提供面向无连接、不可靠的通信服务。

头部只有 8 个字节

TCP与UDP

tcp三个特点、首部-> 拥塞控制流量控制首部长度、一对一一对多、可靠性

1、连接

TCP 是面向连接，传输数据前先要建立连接。
UDP 是不需要连接，即刻传输数据。

2、服务对象

TCP 是一对一的两点服务。
UDP 支持一对一、一对多、多对多的交互通信。

3、可靠性

TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
UDP 是尽最大努力交付，不保证可靠交付数据。

4、传输方式

TCP 是流式传输，没有边界，但保证顺序和可靠。
UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

5、拥塞控制、流量控制

TCP 有拥塞控制和流量控制机制，保证数据传输的安全性。
UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

6、首部长度

TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。
UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

7、分片不同

TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP 数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层。

三次握手

第三次握手是可以携带数据的，前两次握手是不可以携带数据的

如何在 Linux 系统中查看 TCP 状态？

netstat -napt

为什么不是两次四次

防止历史连接的建立
客户端向服务端发送 seq=90，然后客户端宕机并且网络阻塞，服务器没收到，客户端又发送 seq num=100。网络恢复，服务端一定先收到 seq num=90，返回客户端 ack num=91。但客户端希望收到101。于是发给服务端一个拒绝链接(RST)。两次握手就没法实现了。两次握手，当服务端向客户端返回ack num时就已经建立连接可以发送数据，浪费了资源。

同步双方初始序列号
序列号能够保证数据包不重复、不丢弃和按序传输。一来一回的握手能够保证双方的初始序列号能被可靠的同步

不使用「两次握手」和「四次握手」的原因：

「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
「四次握手」：三次握手就已经理论上最少可靠连接建立，第二三次合并成一次，就变成三次握手了。

MTU MSS

MTU最大传输单元：一个网络包的最大长度，以太网中一般为 1500 字节；
MSS最大报文大小：除去 IP 和 TCP 头部之后，一个网络包所能容纳的 TCP 数据的最大长度；

这看起来井然有序，但这存在隐患的，那么当如果一个 IP 分片丢失，整个 IP 报文的所有分片都得重传。

因为 IP 层本身没有超时重传机制，它由传输层的 TCP 来负责超时和重传。

因此，可以得知由 IP 层进行分片传输，是非常没有效率的。

所以，为了达到最佳的传输效能 TCP 协议在建立连接的时候通常要协商双方的 MSS 值，当 TCP 层发现数据超过 MSS 时，则就先会进行分片，当然由它形成的 IP 包的长度也就不会大于 MTU ，自然也就不用 IP 分片了。

经过 TCP 层分片后，如果一个 TCP 分片丢失后，进行重发时也是以 MSS 为单位，而不用重传所有的分片，大大增加了重传的效率。

第一次握手丢失

如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发「超时重传」机制，重传 SYN 报文。

重发的次数由 tcp_syn_retries 参数控制，默认是 5 次：

第二次握手丢失

客户端就会触发超时重传机制，重传 SYN 报文。

服务端这边会触发超时重传机制，重传 SYN-ACK 报文。

容易SYN攻击通过调节参数来控制半连接队列

第三次握手丢失

ACK 报文是不会有重传的，当 ACK 丢失了，就由对方重传对应的报文。

SYN 攻击

解决

1、修改参数

通过修改 Linux 内核参数，控制队列大小和当队列满时应做什么处理。

当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包。控制该队列的最大值如下参数：

net.core.netdev_max_backlog

SYN_RCVD 状态连接的最大个数：

net.ipv4.tcp_max_syn_backlog

超出处理能时，对新的 SYN 直接回报 RST，丢弃连接：

net.ipv4.tcp_abort_on_overflow

2、cookie

正常流程：

当服务端接收到客户端的 SYN 报文时，会将其加入到内核的「 SYN 队列」；
接着发送 SYN + ACK 给客户端，等待客户端回应 ACK 报文；
服务端接收到 ACK 报文后，从「 SYN 队列」移除放入到「 Accept 队列」；
应用通过调用 accpet() socket 接口，从「 Accept 队列」取出连接。

受到 SYN 攻击：

如果不断受到 SYN 攻击，就会导致 SYN 队列（半连接队列）被占满，从而导致无法在建立新的连接。

tcp_syncookies 的方式可以应对 SYN 攻击的方法：

net.ipv4.tcp_syncookies = 1

当「 SYN 队列」满之后，后续服务器收到 SYN 包，不进入「 SYN 队列」；
计算出一个 cookie 值，再以 SYN + ACK 中的「序列号」返回客户端，
服务端接收到客户端的应答报文时，服务器会检查这个 ACK 包的合法性。如果合法，直接放入到「 Accept 队列」。
最后应用通过调用 accpet() socket 接口，从「 Accept 队列」取出的连接。

四次挥手

双方都可发起断开链接

1、客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。

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

客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。

每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。
主动关闭连接的，才有 TIME_WAIT 状态。

为什么是四次

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

第一次挥手丢失

收不到对方的ACK就会触发超时重传机制

第二次挥手丢失

ACK不会重传，还是重传FIN报文

第三次挥手丢失

重传FIN报文

第四次挥手丢失

重传FIN报文

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

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

为什么需要 TIME_WAIT 状态？

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。

需要 TIME-WAIT 状态，主要是两个原因：

防止历史连接中的数据，被后面相同四元组的连接错误的接收；
等待足够的时间以确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。

重传机制

报文丢失解决的方法

TCP 实现可靠传输的方式之一，是通过序列号与确认应答。

在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息

超时重传

TCP 会在以下两种情况发生超时重传：

数据包丢失
确认应答丢失

快速重传

TCP 还有另外一种快速重传（Fast Retransmit）机制，它不以时间为驱动，而是以数据驱动重传。

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

SACK

还有一种实现重传机制的方式叫：SACK（ Selective Acknowledgment）， 选择性确认。

Duplicate SACK

Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。

滑动窗口

TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了，再发送下一个。但这种方式的缺点是效率比较低的。

窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。

窗口大小由哪一方决定？

TCP 头里有一个字段叫 Window，也就是窗口大小。

所以，通常窗口的大小是由接收方的窗口大小来决定的。

发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。

流量控制

TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。

拥塞控制

所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。

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

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

其实只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。

拥塞控制有哪些控制算法？

拥塞控制主要是四个算法：

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

HTTP

概念

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。

请求报文(请求行/请求头/请求数据/空行)

状态码

1xx

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx

3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

4xx

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

常见字段

Host 字段

客户端发送请求时，用来指定服务器的域名。

Host: www.A.com

Content-Length 字段

服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。

Content-Length: 1000

Connection 字段

Connection 字段最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。

HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。

Connection: keep-alive

一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。

Content-Type 字段

Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。

Content-Type: text/html; charset=utf-8

Content-Encoding 字段

Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

Content-Encoding: gzip

GET和POST区别

GET请求不安全，POST相对安全。GET参数通过URL传递，POST放在Request body中。抓包还是能看到请求体的内容，可以用HTTPS避免。
GET只接受 ASCII 字符，而POST没有限制。
GET请求在URL中传送的参数是有长度限制的，而POST没有。
GET请求会被浏览器主动cache，而POST不会。
GET主要是做获取操作，是幂等的，而POST主要是做修改删除增加，不是幂等的。

HTTP缓存

HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存

强制缓存

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存。

强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：

Cache-Control，是一个相对时间；
Expires，是一个绝对时间；

如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control的优先级高于 Expires 。

流程：

第一次请求服务器返回资源同时Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；

协商缓存

协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。

两种实现

第一种：请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段实现，这两个字段的意思是：

响应头部中的 Last-Modified：标示这个响应资源的最后修改时间；
请求头部中的 If-Modified-Since：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，去对比。没过期返回 304 走缓存，过期返回新资源 200

第二种：请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段

响应头部中 Etag：唯一标识响应资源；
请求头部中的 If-None-Match：当资源过期时，浏览器发现响应头里有 Etag，则再次向服务器发起请求时，会将请求头If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。

流程：

两种流程都一样，第一次访问服务器时，服务器响应头部加上 ETag 唯一标识。

Etag 的优先级大于 Last-Modified。
协商缓存这两个字段都需要配合强制缓存中 Cache-control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

HTTP1.1

优点

1、简单

HTTP报文格式就是 header + body，头部信息也是 key-value，易于理解。

2、灵活易扩展

HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。

HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。

HTTPS就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP3把TCP层换成了基于 UDP 的 QUIC

3、应用广泛

从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有跨平台的优越性。

缺点

1、无状态

不用额外的资源去记录状态信息，减轻服务器的负担；没有记忆能力，有关联性操作就会很麻烦

利用 Cookie在请求和响应报文中写入 Cookie 信息来控制客户端状态

2、明文传输不安全

get请求在URL中就能看到，post可以利用抓包。信息裸奔不安全

性能

1、长链接

早期 HTTP/1.0 是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求。HTTP/1.1 提出了长连接的通信方式，也叫持久连接

持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

2、管道网络传输

在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

服务器必须按照接收请求的顺序发送对这些管道化请求的响应。
实际上 HTTP/1.1 管道化技术不是默认开启，而且浏览器基本都没有支持，所以后面讨论HTTP/1.1 都是建立在没有使用管道化的前提。

3、队头阻塞

请求 - 应答 的模式加剧了 HTTP 的性能问题。

优化

1、通过缓存技术避免发送HTTP请求

2、减少重定向请求次数(代理服务器)

3、合并请求减少TCP连接次数，握手时间

4、延迟发送请求(用户滑动在继续请求）

5、压缩(gzip无损压缩、WebP有损压缩)

HTTP1.1比HTTP1.0提高了什么

长链接改善了1.0短连接造成的性能开销
支持管道网络传输，只要第一个请求发出去不必等其回来就可以发送第二个请求

但HTTP1.1还是有性能瓶颈

请求/响应头部未经压缩就发送，首部信息越多延迟越大。只能压缩Body的部分
队头阻塞问题
没有请求优先级控制
请求只能从客户端开始，服务器只能被动响应

HTTP2

1、头部压缩

HTTP/2 会压缩头（Header），协议会帮你消除重复的部分。

2、二进制格式

3、数据流

流代表了一个完整的请求-响应数据交互过程。它具有如下几个特点：

双向性：同一个流内，可同时发送和接受数据。
有序性：流中被传输的数据就是二进制帧 。帧在流上的被发送与被接收都是按照顺序进行的。
并行性：流中的 二进制帧 都是被并行传输的，无需按顺序等待。但却不会引起数据混乱，因为每个帧都有顺序标号。它们最终会被按照顺序标号来合并。
流的创建：流可以被客户端或服务器单方面建立, 使用或共享。
流的关闭：流也可以被任意一方关闭。

客户端建立的 Stream ID必须是奇数号，而服务器建立的 Stream 必须是偶数号。

4、多路复用

5、服务器推送

HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务端不再是被动地响应，可以主动向客户端发送消息。

HTTP/2 有什么缺陷？

HTTP3

HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后，才能处理下一个请求，这属于 HTTP 层队头阻塞。
HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC

1、无队头阻塞

当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。

2、更快的连接建立

HTTP/3 在传输数据前虽然需要 QUIC 协议握手，这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。

3、连接迁移

HTTP3的未来

HTTPS

定义

安全的超文本传输协议，使用传输层安全性(TLS)或安全套接字层(SSL)对通信协议进行加密。也就是 HTTP + SSL(TLS) = HTTPS。

区别

1、HTTP是超文本传输协议，是明文传输，有安全风险，HTTPS 加入了SSL/TLS安全协议，使得报文能够加密传输。

3、HTTP端口是80，HTTPS的端口号是443

4、HTTPS需要向CA申请数字证书。

用途

加密
数据一致性
身份认证

解决

窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。

认识 SSL/TLS

TLS(Transport Layer Security) 是 SSL(Secure Socket Layer) 的后续版本，它们是用于在互联网两台计算机之间用于身份验证和加密的一种协议。

SSL 是一个独立的协议，不只有 HTTP 可以使用，其他应用层协议也可以使用，比如 SMTP(电子邮件协议)、Telnet(远程登录协议) 等都可以使用。

TLS 在根本上使用对称加密和 非对称加密 两种形式。

对称加密

定义

一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密

缺点

如何让双方都用同一个密钥进行数据加密，同时不被别人知道

非对称加密

定义

两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

流程

客户端需要向服务器发送一条数据，浏览器需要保障数据的安全性，加密流程如下：
某网站服务器拥有公钥A与对应的私钥A’
客户端请求服务器的公钥A，公钥A是公开的，可以明文传输
客户端使用公钥A进行加密，将加密的数据发送给服务器
服务器收到数据，使用私钥A`进行解密，拿到数据
反之，服务器向客户端发送数据也是同样的流程。

缺点

非对称加密算法在解决了双方交换密钥的问题，但非对称加密算法非常耗时，而对称加密快很多

非对称加密+对称加密

定义

用非对称加密完成对称加密的密钥交换，之后再用对称加密进行加密

流程

某网站拥有用于非对称加密的公钥A、私钥A’。
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

缺点

某网站有用于非对称加密的公钥A、私钥A’。
浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
通过这一通操作，攻击者就知道服务器和浏览器之间的公钥了，这样，对称加密就形同虚设了。
为什么会发生这样的事？因为浏览器拿到公钥的时候，他无法确定这个公钥是服务器的。在传输过程中，公钥被篡改，一方用篡改后的公钥加密，非对称加密形同虚设。

数字证书

如何证明浏览器收到的公钥一定是该网站的公钥？这个时候，就要引入第三方机构了，也被称作CA机构。

定义

网站只需要向CA机构申领一份数字证书，这份证书里面，包括了网站的公钥，网站的域名和其他一些网站基本信息。

然后CA机构用自己的私钥对证书进行加密，同时生成一段密文，这段密码就叫做数字签名

生成

CA机构拥有非对称加密的私钥和公钥。
网站需要申请数字证书，只需将自己网站的数据给CA机构(网站公钥，网站域名等)
CA机构对证书明文数据进行hash。
对hash后的值用私钥加密，得到数字签名

检验

拿到证书，从证书中得到公钥，数字签名等数据。
用 CA 机构的公钥对数字签名解密（浏览器内置CA机构的公钥），得到S。
用 hash 算法对明文进行hash得到T。
所以此时比较 S 是否等于 T ，等于则表明证书可信。如果证书的数据没有被改动过, S 和 T 应该是相同的，则证书可信任，浏览器就用证书中的公钥加密数据。
如果S和T，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
数字签名是用 CA 机构的私钥加的密，只能用公钥来解密
证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了
一般浏览器会内置主流的CA机构的公钥

IP

认识

IP 在 TCP/IP 参考模型中处于第三层，也就是网络层。

网络层的主要作用是：实现主机与主机之间的通信，也叫点对点（end to end）通信。

网络层与数据链路层

IP 的作用是主机之间通信用的，而 MAC 的作用则是实现直连的两个设备之间通信，而 IP 则负责在没有直连的两个网络之间进行通信传输。

源IP地址和目标IP地址在传输过程中是不会变化的（前提：没有使用 NAT 网络），只有源 MAC 地址和目标 MAC 一直在变化

基础

IP 地址（IPv4 地址）由 32 位正整数来表示，IP 地址在计算机是以二进制的方式处理的。

IP 地址最大值：2的32次方

IP 地址并不是根据主机台数来配置的，而是以网卡。像服务器、路由器等设备都是有 2 个以上的网卡，也就是它们会有 2 个以上的 IP 地址。

无分类地址CIDR

正因为 IP 分类存在许多缺点，所以后面提出了无分类地址的方案，即 CIDR。

这种方式不再有分类地址的概念，32 比特的 IP 地址被划分为两部分，前面是网络号，后面是主机号。

表示形式 a.b.c.d/x，其中 /x 表示前 x 位属于网络号， x 的范围是 0 ~ 32，这就使得 IP 地址更加具有灵活性。

还有另一种划分网络号与主机号形式，那就是子网掩码，掩码的意思就是掩盖掉主机号，剩余的就是网络号。

将子网掩码和 IP 地址按位计算 AND，就可得到网络号。

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

路由器寻址工作中，也就是通过这样的方式来找到对应的网络号的，进而把数据包转发给对应的网络内。

怎么进行子网划分？

可以通过子网掩码划分出网络号和主机号，那实际上子网掩码还有一个作用，那就是划分子网。

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

未做子网划分的 ip 地址：网络地址＋主机地址
做子网划分后的 ip 地址：网络地址＋（子网网络地址＋子网主机地址）

假设对 C 类地址进行子网划分，网络地址 192.168.1.0，使用子网掩码 255.255.255.192 对其进行子网划分。

C 类地址中前 24 位是网络号，最后 8 位是主机号，根据子网掩码可知从 8 位主机号中借用 2 位作为子网号。

由于子网网络地址被划分成 2 位，那么子网地址就有 4 个，分别是 00、01、10、11，具体划分如下图：

公有 IP 地址与私有 IP 地址

私有 IP 地址通常是内部的 IT 人员管理，公有 IP 地址是由 ICANN 组织管理，中文叫「互联网名称与数字地址分配机构」。

IP 地址与路由控制

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

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

IP 分片与重组

我们最常见数据链路是以太网，它的 MTU 是 1500 字节。

那么当 IP 数据包大小大于 MTU 时， IP 数据包就会被分片。

经过分片之后的 IP 数据报在被重组的时候，只能由目标主机进行，路由器是不会进行重组的。

假设发送方发送一个 4000 字节的大数据报，若要传输在以太网链路，则需要把数据报分片成 3 个小数据报进行传输，再交由接收方重组成大数据报。

IPv6

IPv4 的地址是 32 位的，但是 IPv6 的地址是 128 位的

优点

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

标识

IPv4 地址长度共 32 位，是以每 8 位作为一组，并用点分十进制的表示方式。

IPv6 地址长度是 128 位，是以每 16 位作为一组，每组用冒号「:」隔开。

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

IPv6首部

取消了首部校验和字段。 因为在数据链路层和传输层都会校验，因此 IPv6 直接取消了 IP 的校验。
取消了分片/重新组装相关字段。 分片与重组是耗时的过程，IPv6 不允许在中间路由器进行分片与重组，这种操作只能在源与目标主机，这将大大提高了路由器转发的速度。
取消选项字段。 选项字段不再是标准 IP 首部的一部分了，但它并没有消失，而是可能出现在 IPv6 首部中的「下一个首部」指出的位置上。删除该选项字段使的 IPv6 的首部成为固定长度的 40 字节。

DNS

DNS 域名解析，DNS 可以将域名网址自动转换为具体的 IP 地址。

域名的层级关系

域名的层级关系类似一个树状结构：

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

域名解析的工作流程

看 浏览器上输入url经历了什么

ARP

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

ARP 又是如何知道对方 MAC 地址的呢？

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

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

操作系统通常会把第一次通过 ARP 获取的 MAC 地址缓存起来，以便下次直接从缓存中找到对应 IP 地址的 MAC 地址。

不过，MAC 地址的缓存是有一定期限的，超过这个期限，缓存的内容将被清除。

RARP

DHCP

通过 DHCP 动态获取 IP 地址，大大省去了配 IP 信息繁琐的过程。

NAT

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

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

由于绝大多数的网络应用都是使用传输层协议 TCP 或 UDP 来传输数据的。

因此，可以把 IP 地址 + 端口号一起进行转换。

这样，就用一个全球 IP 地址就可以了，这种转换技术就叫网络地址与端口转换 NAPT。

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

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

NAT 那么牛逼，难道就没缺点了吗？

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

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

ICMP

ICMP 全称是 Internet Control Message Protocol，也就是互联网控制报文协议。

功能

确认 IP 包是否成功送达目标地址、报告发送过程中 IP 包被废弃的原因和改善网络设置等。

在 IP 通信中如果某个 IP 包因为某种原因未能达到目标地址，那么这个具体的原因将由 ICMP 负责通知。

类型

ICMP 大致可以分为两大类：

一类是用于诊断的查询消息，也就是「查询报文类型」
另一类是通知出错原因的错误消息，也就是「差错报文类型」