计算机网络原理

计算机网络知识点整理

一、计算机网络体系结构

OSI 的七层 协议体系结构的概念清除，理论也比较完整，但它既复杂又不实用。

TCP/IP 是一个四层 体系结构，TCP/IP体系结构虽然简单，但它现在却得到了非常广泛的使用。

在学习中我们采用折中的办法，学习具有五层协议的原理体系结构

二、五层协议原理体系结构

物理层

物理层是原理体系结构的最底层，负责完成计算机网络中最基础的任务，即在传输媒体上传送比特流 。

物理层作用：

实现计算机结点之间比特流的透明传输。（将数字信号转换为电信号）

规定传输媒体接口标准，屏蔽掉具体传输介质和物理设备的差异，使数据链路层不必关心网络的具体传输介质。

为数据链路层提供服务。

数据链路层

数据链路层位于物理层之上，网络层之下，将网络层传下的IP数据报封装成 帧 ，通过差错控制、流量控制等方法，将分组从链路的一端传送到另一端，丢弃有差错的帧保证物理层收到的分组是无差错的信息。

数据链路层的几个基本方法：

封装成帧：将网络层的IP数据报加头加尾，封装成帧，帧中包括源MAC地址和目的MAC地址。

透明传输：零比特填充，转义字符。

差错检测：接收者检测错误时，如果发现差错，丢弃该帧。差错控制方法有CRC循环冗余校验

流量控制: 控制发送的传输速度，使得接收放来得及接收。传输层TCP也有流量控制功能，但是TCP是端到端的流量控制，链路层是点到点（比如一个路由器到下一个路由器）

网络层（IP层）

网络层负责为分组交换网上的不同 主机间 提供通信服务。

实现网络地址与物理地址的转换，并通过路由选择算法为分组通过通信子网选择最适当的路径。网络层传输的数据单元为 IP数据报（数据报）

运输层（传输层）

运输层负责向两台主机中进程之间的通信提供通用的数据传输服务。

运输层主要的两个运输层协议：

传输控制协议（TCP） :提供面向连接的，可靠的数据传输服务，其数据传输的单位是报文段

用户数据报协议（UDP） :提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性），其数据传输的单位是用户数据报

应用层

为用户的应用进程提供网络通信服务，完成和实现用户请求的各种服务。

三、五层协议模型

该模型展示了主机1 向 主机2 发送数据时数据入协议栈和出协议栈的过程

入栈过程 ：数据发送方每层不断的封装首部和尾部，添加一些传输的信息，确保能传输到目的地。

出栈过程 ：数据接收方每层不断的拆除首部和尾部，得到最终传输的数据。

四、数据链路层

4.1 封装成帧

数据链路层以帧为单位传输和数据处理，网络层的IP数据报必须向下传递到数据链路层，成为帧的数据部分，同时它的前面和后面同时添加了帧首部和帧尾部，封装成一个完整的帧。帧的长度等于帧的数据部分长度加上帧首部和帧尾部的长度。

4.2 透明传输

每个帧首和帧尾都为特定的字符，当我们要传输的数据中出现了与帧首帧尾相同的字符时，原始数据就会被误判帧首帧尾，这时候就需要将数据部分中与帧首帧尾相同的字符用一个转义字符 来填充进行转义，如果原始数据中也出现了转义字符，这时候转义字符也用转义字符转义，从而实现原始数据的透明传输

4.3 差错检测

现实中的通信链路都不会是理想的，比特在传输过程中可能会产生差错：1可能会变成0，而0也可能变成1.这就叫做比特差错 ，为了防止这种差错，在数据链路层通常使用 循环冗余校验（CRC）技术进行差错检测

循环冗余校验计算方法：加法不进位，减法不借位，等价于按位异或（XOR）,乘以2和除以2都等价于左/右移位。

上图为循环冗余校验原理的例子

若得出的余数R=0,则判定这个帧没有差错，就接收。

若余数R≠0，则判断这个帧有差错(但无法确定究竟是哪一位或哪几位出现了差错),就丢弃。

五、网络层（IP层）

5.1 IP地址及编址方式

IP地址

整个因特网就是一个单一的逻辑网络 。IP地址就是给英特网上的每一个主机(或路由器)的每一个接口分配一个在全世界范围是唯一的32的标识符。IP地址的结构使我们可以在因特网上很方便的进行寻址。

为了提高可读性，我们常常把32位的IP地址中的每8位用其等效的十进制数字表示，并且在这些数字之间加上一个点。这种表示称为点分十进制记法

如下图：

编址方式

分类编址 ：这是最基本的方法 ；IP地址::={<网络号>,<主机号>} 缺点：地址分配不灵活，要么太大浪费空间，要么太小不够用。

划分子网 ：在分类编址上的一个改进； IP地址::={<网络号>,<子网号>,<主机号>} 缺点：数量巨大的C类地址因为地址空间太小并没有得到充分利用。

无分类编址 ：目前因特网使用的编址方法。IP地址::={<网络前缀>,<主机号>}

下面重点介绍一下无分类编址：

无分类编址的网络前缀是不定长的，用来代替分类编址的’‘网络号’'并指明网络，后面的部分则用来指明主机。

网络前缀计算方式：只需要将子网掩码和IP地址进行逐位的“与”运算，就可以得出其网络地址（主机号全为0的地址）。

相同IP地址和不同的子网掩码得到的网络地址：

这两个例子说明，相同的IP地址和不同的子网掩码可以得出相同的网络地址，但是不同的子网掩码效果是不同的。虽然这两个例子中网络地址空间起始地址是一样的，但是最大地址是不一样的，各自容纳的最大主机数都是不一样的。

5.2 地址解析协议（ARP）

我们知道，网络层使用的是IP地址，但在具体物理网络的链路上传送数据帧时，最终还是必须使用该物理网络的物理地址。但IP地址和物理网络地址又不是单一的映射关系，这时候就需要用到 地址解析协议(ARP)

ARP地址解析协议工作原理

ARP是根据IP地址获取MAC地址的一种协议，核心原理就是广播发送ARP请求，单播发送ARP响应。

每个主机都有自己的ARP高速缓存，在缓存中都存放有一个从IP地址到物理地址的映射表，并且这个映射表不断动态更新。(新增或超时删除)

当源主机要发送数据时，先检查ARP列表中是否有该IP地址对应的MAC地址，如果有，则直接发送数据；如果没有，就向本网段的所有主机发送ARP数据包，用于查询目的主机的MAC地址，该数据包包括的内容有：源主机IP地址，源主机MAC地址，目的主机的IP。

当本网络的所有主机收到该ARP数据包时，首先检查该包中的IP是否与自身IP相同。若不同，则丢弃数据包，如果是，则先取出该数据包的源主机IP地址和MAC地址写入到自身的ARP高速缓存映射列表中。如果已经存在，就覆盖。然后将自己的MAC地址写入到ARP响应包中，告诉源主机自己的IP地址和MAC地址。

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

5.3 ICMP协议

因特网控制报文协议，用于在IP主机、路由器之间传递控制信息(控制信息是指网络通不通，主机是否可达，路由器是否可用等网络本身的信息)，确认IP包是否成功到达目的地址。因为IP协议并不是一个可靠的协议，它不保证数据被送达，当传送IP数据包发生错误，比如主机不可达、路由不可达等等，ICMP协议将会把错误信息封包，然后传回给主机，给主机一个处理错误的机会。

5.3.1 ICMP报文的种类

ICMP报文的种类有两种，即ICMP差错报告报文 和ICMP询问报文

ICMP差错报告报文

终点不可达 ：当路由器或主机不能交付数据报时，就向源点发送终点不可达报文。具体可再根据ICMP的代码字段细分为目的网络不可达、目的主机不可达、目的协议不可达、目的端口不可达、目的网络未知、目的主机未知等。

源点抑制 ：当路由器或主机由于拥塞而丢弃数据报时，就向源点发送源点抑制报文，使源点知道应该应该把数据报的发送速率放慢。

时间超过 ：当路由器收到一个IP数据报，若目的地址不是自己，会将其TTL减1再转发出去，但当TTL减为零时，除丢弃该数据报外，还要向源点发送超时差错报告报文。另外，当终点在预先规定的时间内不能收到一个数据报的全部数据报的全部数据报片时，就把已收到的数据报片丢弃，也会向源点发送超时差错报告报文。

参数问题 ：当路由器或目的主机收到的数据报的首部中有的字段的值不正确时，就丢弃该数据报，并向源点发送参数问题报文。

改变路由(重定向) :路由器把改变路由报文发送给主机，让主机知道下次应将数据报发送给另外的路由器(可通过更好的路由)。

ICMP询问报文

会送请求和回答 ：ICMP回送请求报文是由主机或路由器向一个特定的目的主机发出的询问。收到此报文的主机必须给源主机或路由器发送ICMP回送回答报文。这种询问报文用来测试目的站是否可达及了解其有关状态。

时间戳请求和回答 ：ICMP时间戳请求报文是请求某个主机或路由器回答当前的日期和时间。在ICMP时间戳回答报文中有一个32位的字段，其中写入的整数代表从1900年起1月1日到当前时刻一个多少秒。时间戳请求与回答可用来进行时钟同步和测量时间。

5.4 路由选择协议

内部网关协议(IGP)

内部网关协议即在一个自治系统内部使用的路由选择协议，而这与在互联网中的其他自治系统选用什么路由选择协议无关。目前这类选择协议很多，如RIP 和OSPF 协议。

RIP :是一种动态路由选择协议，基于距离矢量算法，使用“跳数”来衡量到达目标地址的路由距离，并且只与自己相邻的路由器交换信息，范围限制在15跳之内。

OSPF :开放最短路径优先协议，使用Dijskra算法计算出到达每一网络的最短路径，并在检测到 链路的情况发生变化时（如链路失效），就执行该算法快速收敛到新的无环路拓扑。

外部网关协议(EGP)

若源主机和目的主机处在不同的自治系统中(这两个自治系统可能使用不同的内部网关协议)，就需要在自治系统之间进行路由选择，使用一种协议将路由信息从一个自治系统传递到另一个自治系统中。这样的协议就是外部网关协议EGP。目前因特网使用的外部网关协议就是BGP的版本4。

BGP :边界网关协议，BGP 是力求寻找一条能够到达目的网络 且 较好的路由，而并非要寻找一条最佳路由。BGP采用路径向量路由选择协议。

自治系统之间的路由选择也叫作域间路由选择 ，而在自治系统内部的路由选择叫作域内路由选择

六、传输层(运输层)

传输层主要提供不同主机上进程间 逻辑通信+可靠传输 或者 不可靠传输的功能。

6.1 TCP 和UDP

6.1.1 传输控制协议(TCP)和用户数据报协议(UDP)的区别。

TCP是面向字节流的，基本传输单位是TCP报文段；UDP是面向报文的，基本传输单位是用户数据报；

面向字节流：应用程序和TCP的交互是一次一个数据块(大小不等)，但TCP把应用程序看成一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。

面向报文：面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，因此，应用程序必须选择合适大小的报文。太大会造成IP层对数据进行分片，降低IP层效率；太小会造成首部相对较大，降低IP层效率。

TCP注重安全可靠性，连接双方在通信前要进行三次握手建立连接。UDP是面向无连接的，使用最大努力交付，即不保证可靠交互。

UDP不需要等待，所以数据传输较快，TCP传输效率相对较低。

TCP首部开销是20个字节，UDP首部开销是8个字节，UDP减少了网络传输的部分开销。

TCP有流量控制和拥塞控制，UDP没有流量控制和拥塞控制。

TCP支持点对点通信，提供全双工通信，不提供广播或者多播服务；UDP支持一对一，一对多，多对一，多对多的通信模式。

6.1.2 TCP和UDP的适用场景

当对网络通信质量要求不高，并且要求网络通信速度尽量的快，这时就可以使用UDP。比如即时通信：语音、视频、直播等。

当对网络通信质量有要求时，要求整个数据准确无误可靠的传递给对方，这时就适合使用TCP协议，一般用于文件传输、发送和接收邮件等场景。比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议都是使用的TCP协议。

使用UDP和TCP协议的各种应用和应用层协议 ：

6.1.3 TCP的报文格式

源端口和目的端口 ：分别占用16位，指发送方应用程序的端口和目的方应用程序的端口号，通过 IP 地址 + 端口号就可以确定一个进程地址

序号(Sequense Number,SN) ：在一个TCP连接中传送的字节流中每一个字节都按照顺序编号，该字段表示本报文段所发送数据的第一个字节的序号。(初始序号称为 Init Sequence Number，ISN)

例如，一报文段的序号是 101，共有 100 字节的数据。这就表明：本报文段的数据的第一个字节的序号是 101，最后一个字节的序号是 200。显然，下一个报文段的数据序号应当从 201 开始，即下一个报文段的序号字段值应为 201。

确认号ack :期望收到对方下一个报文段的第一个数据字节的序号。若确认号为 N，则表明：到序号 N-1 为止的所有数据都已正确收到。

数据偏移 ：指出 TCP报文段的数据起始处 距离 TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。

保留位 ：占6位，应置为 0，保留为今后使用。

6个控制位 ：用于说明该报文段的性质：

紧急位URG：当 URG = 1 时，表明此报文段中有紧急数据，是高优先级的数据，应尽快发送，不用在缓存中排队。

确认ACK：仅当 ACK = 1 时确认号字段才有效，当 ACK = 0 时确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置为 1。

推送PSH：接收方收到 PSH = 1 的报文段时，就直接发送给应用进程，而不用等到整个缓冲区都填满了后再向上传送。

复位RST：当 RST = 1 时，表明 TCP 连接中出现了严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立传输连接。

同步SYN：SYN = 1 表示这是一个连接请求或连接接受报文。当 SYN = 1 而 ACK = 0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN = 1 且 ACK = 1。

终止FIN：用来释放一个连接。当 FIN = 1时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接。

窗口大小 ：16位，用于控制发送端的滑动窗口大小

校检和 ：16位，校验数据段是否未被修改

紧急指针 ：16位。

6.2 TCP连接的建立和断开

6.2.1 TCP三次握手建立连接

客户机A主动发送一个SYN报文 ，该报文指明了第一个字节的初始化序列号(ISN)即seq=x；此时客户端处于SYN-SENT状态

三次握手的一个重要功能是客户端和服务端交换 ISN，以便让对方知道接下来接收数据时如何按序列号组装数据。

ISN 是动态生成的，并非固定，因此每个连接都将具有不同的 ISN。如果 ISN 是固定的，攻击者很容易猜出后续的确认号。

服务器B在收到客户机A发送的SYN报文后，由于SYN=1知道客户端请求建立连接，这时会对这个TCP连接分配缓存和变量(缓冲指的是一个字节流队列)，接着返回客户端一个确认报文 ：设置SYN=1,ACK=1(表示确认号有效) 同时指定自己的初始化序列号ISN,即seq=y,并把客户端的ISN+1作为自己的ack值，表示已经收到客户端发送来的SYN报文，希望收到的下一个数据的第一个字节的序号是x+1,此时服务端进入SYN-RCVD状态。

客户端在收到服务器发送的确认报文后，检查ACK是否为1，ack是否是x+1,如果正确，则给服雾端发送一个ACK报文：设置ACK=1,把服务端的初始化序列号(ISN+1)设置为自己的ack,即ack=y+1,表示已经收到服务端的确认报文，希望收到服务端的下一个数据的字节序号是y+1,并指明此时客户端的初始化序列号为x+1,即seq=x+1,此后客户端和服务端状态都变为ESTABLISHED。完成三次握手，此后服务器和客户端就可以开始传输数据了。

此时SYN控制位已经变成0，表示这不是建立连接的请求了，要正式发送数据了。

6.2.2 为什么不能使用两次握手建立连接

两次握手就只能让服务器端对客户端的初始化序列(ISN)进行确认，并不能让客户端对服务器端的初始化序列进行确认，不能达到可靠传输的目的。

三次握手可以防止已失效的连接请求报文段突然又传送到了服务端，导致服务器错误地建立连接，浪费服务端的连接资源。

客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达Server。本来这是一个早已失效的报文段，但Server收到此失效的连接请求报文段后：

(1) 假设不采用“三次握手”，那么只要Sever发出确认，新的连接就建立了。但由于现在Client并没有发出建立连接的请求，因此不会理睬Server的确认，也不会向Server发送数据。而Server却以为新的连接已经建立，并一直等待Client发来数据，这样，Server的很多资源就白白浪费掉了

(2) 而采用“三次握手”协议，只要Server收不到来自Client的确认，就知道Client并没有要求建立请求，就不会建立连接了。

6.2.3 TCP四次挥手释放连接

第一次挥手 ：客户端发送FIN报文，设置FIN=1,并指定序列号seq=u(u是之前传过来的最后一个字节的序号+1)，主动关闭TCP连接，此时客户端进入FIN-WAIT_1状态。

第二次挥手 ：服务端收到 FIN 报文后，由FIN=1 知道客户端请求关闭连接，则返回确认报文：设置ACK = 1，ack = u + 1，seq = v（v 的值取决于服务器发送给客户端之前的一个包确认号是多少）

服务端进入CLOSE_WAIT状态，此时TCP连接处于半关闭状态，即客户端不能向服务端发送报文，只能接收，但服务端仍然可以向客户端发送数据。

客户端收到服务端的确认后，进入 FIN_WAIT_2 状态，等待服务端发出的连接释放报文段。

第三次挥手 :当服务端没有要向客户端发送的数据时，就向客户端发送一个 FIN 报文，设置 FIN = 1 并指定序列号 seq = w（w 的值取决于服务器发送给客户端之前的一个包确认号是多少），用于关闭服务端到客户端的数据传送。此时服务器处于 LAST_ACK 状态

第四次挥手 :客户端收到 FIN 报文后，发送给服务端一个 ACK 报文作为应答：设置 ACK=1 和 ack = w +1。发送之后，客户端处于 TIME_WAIT状态，如果服务端接收到这个数据包，则进入CLOSED状态，完成四次挥手。

6.2.4 为什么需要TIME-WAIT状态

TIME_WAIT 状态持续 2MSL（最大报文存活时间），约4分钟才转换成CLOSE状态。由于TIME_WAIT 的时间会非常长，因此服务端应尽量减少主动关闭连接，TIME_WAIT 的主要作用有：

重发丢失的ACK报文，保证连接可靠关闭

如果客户端连接没有TIME-WAIT状态，收到服务器的FIN报文就直接关闭，由于网络传输的原因，可能客户端发送的ACK报文在服务器端没有被接收，这就导致服务器端无法确认客户端的连接关闭，重而再次发送FIN报文这时，客户端并不能接收到FIN报文，导致连接异常关闭，就只关闭了客户端，没有关闭服务端。

保证本次连接的重复数据段从网络中消失。

如果存在两个连接，第一个连接正常关闭，第二个相同的连接紧接着建立；如果第一个连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达，则会干扰第二连接，等待 2MSL 可以让上次连接的报文数据消逝在网络中。

6.2.5 为什么需要4次挥手

TCP是全双工模式，并且支持半关闭状态特性，提供了连接的一端在结束发送后还能接收来自另一端数据的能力。在前面四次挥手图解中我们能看到：前面两次挥手是为了关闭客户端到服务端的连接，客户端处于半关闭状态，但是服务端还有发送数据的能力，后两次挥手是为了让服务端也关闭发送数据的能力，从而达到双方都全部释放连接的目的。

两次挥手只能释放一端到另一端的连接，要释放两端的连接就需要四次挥手。

6.3 TCP可靠性传输

6.3.1 TCP如何保证可靠性传输

三次握手 ：同步客户端和服务端的序列号。

应答机制和超时重传 ：应答机制就是TCP接收端累积接收到发送端发来的数据后要对发来的数据进行一个累积确认。超时重传就是当TCP发送端发送一个报文段后，它会启动一个定时器，等待接收端的确认报文，如果确认报文不能及时收到，将重发这个报文段。

数据包校验和丢弃重复数据 ：接收方若收到有差错的报文段就丢弃(不发送否认信息)。若收到重复的报文段，也要丢弃，但是要立即发回确认信息。

对失序数据包进行重排序 ：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；

流量控制 ：TCP连接的主机两端都设置有缓存区，为了防止数据溢出缓存区，TCP通过可变大小的滑动窗口 来控制数据传输的流量大小。

拥塞控制 ：网络拥塞时，减少数据的发送。

6.3.2 TCP的流量控制

流量控制的基本方法就是接受方根据自己的接收能力控制发送方的发送速率 。因此可以说流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读速率相匹配，利用滑动窗口机制可以很方便的控制发送方的平均发送速率，TCP采用接收方控制发送方发送窗口的大小的方法来实现在TCP连接上的流量控制。在TCP报文段首部的窗口字段写入的数值就是当前给对方设置的发送窗口数值上限。

流量控制实例

设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。假设每一个报文段为100字节长，而数据报文段序号的初始值设为1。

从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ，只有在 ACK=1 时确认号字段才有意义。

6.3.3 TCP的拥塞控制

当网络中出现太多分分组时，网络的性能开始下降，这种情况称为拥塞 。

如果网络中的负载 ，即发送到网络中的数据量，超过了网络的容量，即网络中能处理的数据量，那么在网络中就可能发生拥塞。

拥塞控制 的任务就是控制源点的发送速率，防止过多的数据注入到网络中，使网络中的路由器或链路不致过载。

发送方维持一个叫做拥塞窗口 cwnd(congestion window)的状态变量。发送窗口不能大于拥塞窗口

拥塞窗口的大小随网络拥塞情况而动态变化：

只要网络没有出现拥塞，拥塞窗口就增大，以便把更多的分组发送出去

但只要网络出现拥塞，拥塞窗口就减小，以减少注入到网络中的分组数。

慢启动算法

刚建立连接准备发送数据时不知道网络可用宽带情况，先慢慢发送，再逐步提高发送速率，试探网络可用宽带。

一开始发送方先设置拥塞窗口 cwnd=1(一个最大报文段MSS数值)。然后每经过一个传输轮次RTT，拥塞窗口就加倍 。

为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个 慢启动门限 ssthresh 状态变量 。

当 cwnd < ssthresh 时，使用上述的慢开始算法。

当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。

拥塞避免算法

由于慢启动窗口很快，为避免很快又导致网络拥塞，在cwnd>ssthresh时就进入拥塞避免阶段，让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

无论在慢开始阶段还是在拥塞避免阶段，只要网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的拥塞窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd 设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的数据量，使得发生拥塞的路由器有足够时间把队列中积压的数据处理完毕。过程图如下：

快重传

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（使发送方及早知道有报文段没有到达对方）而不必等到自己发送数据时捎带确认。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

如上图：接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让 发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了 接收方的四个对M2的确认，其中后三个都是重复确认。

快速恢复

收到连续三个冗余ACK说明网络出现轻度拥塞，将拥塞窗口直接降低为1则反映过于激烈，这会导致发送方要经过很长时间才能恢复到正常的传输速率。因此TCP规定当发送方收到连续三个冗余ACK时，执行快速恢复算法，将拥塞窗口减半，直接进入拥塞避免。

6.3.4 流量控制和拥塞控制的差别

相同点：拥塞控制和流量控制的相同点都是控制丢包现象，实现机制都是让发送方发得慢一点。

不同点：

拥塞控制是一个全局性的过程，防止过多的数据注入到网络中，造成网络拥塞

流量控制指点对点通信量的控制，要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。

七、应用层

7.1 域名系统(DNS)

域名系统(Domain Name System,DNS)并不是直接和用户打交道的网络应用，而是为其他网络应用提供一种核心服务，即名字服务，使各种网络应用能够在应用层使用计算机的名字来进行交互，而不需要直接使用IP地址。

7.1.1 域名服务器

域名服务器大致分为三种类型：根域名服务器、顶级域名服务器、权限域名服务器 ，其中顶级域名服务器主要负责诸如com、org、net、edu、gov等顶级域名。

根域名服务器存储了所有的顶级域名服务器的IP地址，可以通过根服务器找到顶级域名服务器(例如：www.baidu.com 根服务器会返回所有维护com这个顶级域服务器的IP地址)。

然后你任选其中一个顶级域服务器发送请求，该顶级域服务器拿到域名后能够给出负责当前域的权限服务器地址（以 baidu为例的话，顶级域名服务器将返回所有负责 baidu 这个域的权限域名服务器地址）。

接着任选其中一个权威服务器地址查询 「www.baidu.com」 的具体 IP 地址，最终权威服务器会返回给你具体的 IP 地址。此外，本地 DNS 服务器是具有缓存功能的，通常两天内的记录都会被缓存。

7.1.2 域名解析过程

操作系统先查询本地hosts文件 中是否有录，如果有，则直接返回相映射的IP地址。

如果本地hosts文件没有配置，则主机向自己的本地DNS服务器 发送查询报文，如果本地DNS服务器缓存中有，将直接返回结果。

如果本地服务器缓存中没有，则从内置在内部的根服务器 列表（全球13台，固定的IP地址）中选一个发送查询报文

根服务器解析域名中的后缀名，告诉本地服务器负责该后缀名的所有顶级服务器列表

本地服务器选择其中一个顶级域服务器发送查询请求，顶级域服务器拿到域名后继续解析，返回对应域的所有权限服务器 列表

本地服务器再向返回的权威服务器发送查询报文，最终会从某一个权威服务器上得到具体的 IP 地址

主机返回结果IP

7.1.3 DNS底层协议

DNS域名系统：用于域名解析服务，将域名地址转换为IP地址，基于UDP服务，使用53端口。

DNS底层既使用TCP又使用UDP协议：

(1) 域名解析时使用UDP协议：客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可，不用经过TCP三次握手，这样DNS服务器负载更低，响应更快。

(2) 区域传送时使用TCP，主要有一下两点考虑：

辅助域名服务器会定时（一般时3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。

TCP是一种可靠的连接，保证了数据的准确性。

7.2 HTTP协议：

http协议即超文本传输协议，基于TCP协议，用于从Web服务器传输超文本到本地浏览器的传送协议。

7.2.1 Cookie 和 session的区别

http协议是无状态协议，自身不对请求和响应直接的通信状态进行保存，但有些场景下我们需要保存用户的登录信息，因此引入了cookies和session来管理状态。

cookie和session的区别

保存位置与安全性：cookie保存在客户端，session保存在服务端，所以在安全性方面，cookie存在安全隐患，可以通过拦截本地文件找到cookie后进行攻击，而session相对更加安全。因此，可以将登陆信息等重要信息保存在session中；其他信息如果需要保留，可以存在cookie中。

存储容量：单个cookie最大只允许4KB，一个站点最多保存20个Cookie；session没有大小限制，个数只跟服务器的内存大小有关。

有效期于实现机制：cookie可以长期有效存在；session依赖于cookie，过期时间默认为-1，只需关闭窗口该session就会失效。每个客户端对应一个session，客户端之间的session相互独立；

cookie：cookie是一小段的文本信息，当客户端请求服务器时，如果服务器需要记录该用户状态，就在响应头中向客户端浏览器颁发一个Cookie，而客户端浏览器会把cookie保存起来。当再次请求该网站时，浏览器把请求的网站连同该cookie一起提交给服务器，服务器会检查该cookie，以此来辨认用户状态。

session：当客户端请求服务器时，都会带上cookie，cookie里面一般都会有一个JSESSIONID，服务器就按照 JSESSIONID 来找到对应的 session；如果客户端请求不包含 JSESSIONID，则为此客户端创建session并生成相关联的JSESSIONID，并将这个JSESSIONID在本次响应中返回给客户端保存。客户端保存这个 JSESSIONID 的方式可以使用cookie机制。若浏览器禁用Cookie的话，可以通过 URL重写机制 将JSESSIONID传回服务器。

7.2.2 一个完整的http请求是怎样的？

用户在浏览器端输入某一URL点击回车，或者点击某一超链接整个http请求流程：

解析URL,获取URL中包含的域名；

通过DNS系统查询域名对应的IP;

浏览器得到域名对应的IP后，向服务器发起三次握手，建立TCP连接；

TCP连接建立起来后，浏览器向服务器发送http请求，如果HTML文件在缓存中，浏览器则直接返回，如果没有，则去服务器端拿；

(1) 浏览器首次加载资源成功时，服务器返回200，此时浏览器不仅将资源下载下来，而且把response的header(里面的date属性非常重要，用来计算第二次相同资源时当前时间和date的时间差)一并缓存;

(2) 下一次加载资源时，首先要经过强缓存的处理，cache-control的优先级最高，比如cache-control：no-cache,就直接进入到协商缓存的步骤了，如果cache-control：max-age=xxx,就会先比较当前时间和上一次返回200时的时间差，如果没有超过max-age，命中强缓存，不发请求直接从本地缓存读取该文件（这里需要注意，如果没有cache-control，会取expires的值，来对比是否过期），过期的话会进入下一个阶段，协商缓存

(3) 协商缓存阶段，则向服务器发送header带有If-None-Match和If-Modified-Since的请求，服务器会比较Etag，如果相同，命中协商缓存，返回304；如果不一致则有改动，直接返回新的资源文件带上新的Etag值并返回200;

(4) 协商缓存第二个重要的字段是，If-Modified-Since，如果客户端发送的If-Modified-Since的值跟服务器端获取的文件最近改动的时间，一致则命中协商缓存，返回304；不一致则返回新的last-modified和文件并返回200;

服务器接收到请求后，根据路径映射到特定的处理器进行处理，并将处理结果以及相应的视图返回给浏览器。

浏览器解析视图，并根据请求到的资源，数据进行渲染页面，最终向用户呈现一个完整的页面。

构建DOM树(DOM tree)：从上到下解析HTML文档生成DOM节点树（DOM tree），也叫内容树（content tree）；

构建CSSOM(CSS Object Model)树：加载解析样式生成CSSOM树；

执行JavaScript：加载并执行JavaScript代码（包括内联代码或外联JavaScript文件）；

构建渲染树(render tree)：根据DOM树和CSSOM树,生成渲染树(render tree)；

渲染树：按顺序展示在屏幕上的一系列矩形，这些矩形带有字体，颜色和尺寸等视觉属性。

布局（layout）：根据渲染树将节点树的每一个节点布局在屏幕上的正确位置；

绘制（painting）：遍历渲染树绘制所有节点，为每一个节点适用对应的样式，这一过程是通过UI后端模块完成；

7.2.3 http的长链接和短连接

http的长连接和短连接其本质是TCP的长链接和短连接，从http1.1开始就默认使用长链接。

短连接 ：客户端向服务端每发送一次请求，就会去建立一次TCP连接，收到服务端响应，请求完毕后就断开TCP连接。

长连接 ：客户端和服务器端建立起TCP连接后，他们之间的连接会持续存在，不会应为一次HTTP请求后关闭，后续的请求也用这个连接进行通信，使用长连接的HTTP协议，会在响应头加入：Connection：keep-alive。长连接可以省去每次建立连接和断开的握手和挥手操作，节约时间提高效率。但在长连接下，客户端一般不会主动关闭连接，如果客户端和服务端之间的连接一直不关闭的话，随着连接数越来越多，会对服务端造成压力。

各自适用场景 ：长连接适合频繁请求资源并且连接数并不多的场景，例如数据库的连接使用长连接。而向Web网站这种并发量大，但是每个用户无需频繁操作的场景，一般都使用短连接，因为长连接对服务端来说会消耗一定的资源。

7.3 HTTPS协议

https 是基于tcp协议，在http的基础上加入了SSL/TLS，可看成是添加了加密和认证机制的http，使用对称加密、非对称加密、证书等技术进行进行客户端与服务端的数据加密传输，最终达到保证整个通信的安全性。

对称加密：对称加密指加密和解密都需要同一个密钥，这种方式存在如何安全的将密钥发送对方的问题。

非对称加密：非对称加密使用两个密钥，公钥加密则需要私钥解密，私钥加密则需要公钥解密，不能同一个秘钥既加密又解密。

非对称加密不需要发送用来解密的私钥，所以可以保证安全性，但是和对称加密相比，速度非常慢，所以我们还是用对称加密进行数据传输，但对对称加密的秘钥用非对称加密加密的方式发送出去。

7.3.1 HTTPS的认证加密过程是如何保证内容不被篡改的？

HTTPS是基于TCP协议的,首先客户端会和服务端发起连接建立；

服务端返回他的证书给客户端，证书中包含了服务端公钥S.pub、颁发机构和有效期等信息；

客户端通过浏览器内置的的根证书(内部包含CA机构的公钥C.pub) 验证证书的合法性；

客户端生成随机的对称加密秘钥Z,然后通过服务端的公钥S.pub加密发送给服务端；

客户端和服务端之后就通过对称加密秘钥Z加密数据进行http通信。

7.3.2 根证书是如何保证签发的证书是安全有效的？

服务器会预先生成非对称加密秘钥，私钥S.pri自己保留，而公钥S.pub则发送给CA机构进行签名认证，当我们在使用HTTPS的时候都必须要先去CA机构申请一份证书 ；

CA机构也会预先生成非对称加密秘钥，其私钥C.pri用来对服务器的公钥S.pub进行签名，生成CA证书；

CA机构将签名生成的CA证书返回给服务器，也就是前面服务端给客户端那个证书；

因为CA机构比较权威，所以很多浏览器会内置包含它公钥C.pub的证书，称之为根证书，然后可以使用根证书来验证其颁发证书的合法性了。

整个过程中一共涉及到2对公私密钥对，一对由服务器产生，用于加密对称秘钥，一对由CA机构产生，用于生成证书验证服务器的公钥S.pub是否合法。

7.3.3 为什么需要CA证书认证机构呢？

CA机构的作用就是保证服务器端的公钥是准确无误的，合法未修改的；虽然HTTPS是加密的，但是请求还是会被拦截，假设没有CA证书，如果服务器返回的包含公钥的数据包被攻击人截取，然后攻击人也生成一份自己的公私钥，他将自己的公钥发送给客户端，攻击者得到客户端的数据进行解密后，然后再通过服务器的公钥加密发送给服务器，这样数据就被攻击者获取到了。

所以当我们在使用HTTPS协议的时候都必须提前向CA机构申请一份自己的CA证书用来作为持有者的身份证唯一标识；然后浏览器内置的根证书能够验证服务器发来的证书是否合法有效，如果是攻击者的伪造证书很容易发现证书中的网站信息不合法。从而达到了服务器的公钥实现秘密传输给客户端的效果。

证书内容通常包括：

服务端的公钥

证书发行者（CA）对证书的数字签名

证书所用的签名算法

证书发布机构、有效期、所有者的信息等其他信息

7.4 HTTP的请求和响应

7.4.1 HTTP的常见请求方式：

get ：向服务器端获取资源，所以一般查询采用get请求；

post ：向服务器端提交请求字段，创建操作使用post请求，该操作不是幂等的，多次请求会导致多条数据被创建，所以一般新增操作用post请求；

put :修改自定URL的资源，如果指定资源不存在，则进行创建，在http中，put被定义为幂等的，多次操作会导致前面的数据被覆盖，所以一般修改操作用put请求；

patch ：局部修改URL所在资源的数据，是对put的补充；

delete ：删除指定的URL资源。一般删除操作用delete请求；

head ：获取响应报文的首部，即获取URL资源的头部；

options :询问服务器支持哪些方法，响应头中返回Allow：GET、POST、HEAD;

trace :追踪路径，主要用于测试或诊断；在请求头中在Max-Forwards字段设置数字，每经过一个服务器该数字就减一，当到0的时候就直接返回，一般通过该方法检查请求发送出去是否被篡改

7.4.2 get和post请求的区别

功能：get一般用于从服务器上面获取资源，post一般用来更新服务器上面的资源。

幂等性：get是幂等的，post是非幂等的

安全性：get请求的参数会被明文附加在URL之后，而post请求提交的数据会被封装到请求体中，相对更安全

传输数据量的大小：get请求允许发送的数据量比较小，大多数浏览器都会限制请求的url长度在2048个字节，而大多数服务器最多处理64K大小的url；而post请求提交的数据量则是没有大小限制的。

参数的数据类型：get只接受ASCII字符，而post没有限制。

get在浏览器回退时是无害的，而post会再次提交请求。

get请求可以被缓存，可以被保留在浏览器的历史记录中；post请求不会被缓存，不会被保留在浏览器的历史记录中。

7.4.3 HTTP报文头分析

HTTP报文是面向文本 的，因此在报文中的每一个字段都是一些ASCII码串。

报文类型分两种：请求报文，响应报文

请求报文：

请求行：包含请求方法、URI、HTTP版本信息

请求首部字段

请求内容实体

响应报文：

状态行：包含HTTP版本、状态码、状态码的原因短语

响应首部字段

响应内容实体

报文中各部分的简要描述：

方法(method) ：客户端希望服务器对资源执行的动作，是一个单独的词，比如：get 或者 post

请求URL(request-URL) ：请求URL是资源的绝对路径，服务器可以假定自己是URL的主机/端口

版本(version) ：报文所使用的Http版本，其格式：HTTP/<主要版本号>.<次要版本号>

状态码(status-code) ：标识请求过程中所发生的情况

原因短语(reason-phrase) ：数字状态码的可读版本，包含行终止序列之前的所有文本。

请求头部(header) ：可以有零个或多个头部，每个首部都包含一个名字，后面跟着一个冒号( : )，然后是一个可选的空格，接着是一个值，最后是一个CRLF首部是由一个空行(CRLF)结束的，表示了头部列表的结束和实体主体部分的开始

实体的主体部分(entity-body) ：实体的主体部分包含一个由任意数据组成的数据块，并不是所有的报文都包含实体的主体部分，有时，报文只是以一个CRLF结束。

通用头部：既可以出现在请求报文中，也可以出现在响应报文中，它提供了与报文相关的最基本的信息：

Connection ：允许客户端和服务器指定与请求/响应连接有关的选项，http1.1之后默认是 keep-alive

Date ：日期和时间标志，说明报文是什么时间创建的

Transfer-Encoding ：告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式

Cache-Control ：用于随报文传送缓存指示

请求头部：请求头部是只在请求报文中有意义的头部。用于说明是谁或什么在发送请求、请求源自何处，或者客户端的喜好及能力

Host：给出了接收请求的服务器的主机名和端口号

Referer：提供了包含当前请求URI的文档的URL

User-Agent：将发起请求的应用程序名称告知服务器

Accept：告诉服务器能够发送哪些媒体类型

Accept-Encoding：告诉服务器能够发送哪些编码方式

Accept-Language：告诉服务器能够发送哪些语言

Range：如果服务器支持范围请求，就请求资源的指定范围

If-Range：允许对文档的某个范围进行条件请求

Authorization：包含了客户端提供给服务器，以便对其自身进行认证的数据

Cookie：客户端用它向服务器传送数据

响应头部：响应头部为客户端提供了一些额外信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令

Age：(从最初创建开始)响应持续时间

Server：服务器应用程序软件的名称和版本

Accept-Ranges：对此资源来说，服务器可接受的范围类型

Set-Cookie：在客户端设置数据，以便服务器对客户端进行标识

实体首部：描述主体的长度和内容，或者资源自身

Allow：列出了可以对此实体执行的请求方法

Location：告知客户端实体实际上位于何处，用于将接收端定向到资源的位置(URL)上去

Content-Base：解析主体中的相对URL时使用的基础URL

Content-Encoding：对主体执行的任意编码方式

Content-Language：理解主体时最适宜使用的自然语言

Content-Length：主体的长度

Content-Type：这个主体的对象类型

ETag：与此实体相关的实体标记

Last-Modified：这个实体最后一次被修改的日期和时间

7.4.4 HTTP常见的状态码：

1xx:请求处理中，请求已被接受，正在处理。

2xx:请求成功，请求被成功处理。

200：OK,客户端请求成；

204：请求处理成功，但没有资源返回；

3xx:重定向，要完成请求必须进一步处理。

301：永久性转移，请求的资源已经被分配到了新的地址

302：暂时重定向

304：已缓存。

4xx:客户端错误，请求不合法。

400：客户端请求报文出现错误，通常是参数错误

401：客户端未认证授权

403：没有权限访问该资源

404：未找到请求的资源

405：不支持该请求方法，如果服务器支持GET，客户端用POST请求就会出现这个错误码

5xx:服务端错误，服务端不能处理合法请求。

服务器内部错误。

服务不可用，一段时间后可能恢复正常。

7.4.5 HTTP/1.1和HTTP/2.0的区别：

多路复用：做到同一个连接并发处理多个请求：HTTP2.0 使用了多路复用的技术，做到同一个连接并发处理多个请求，并发请求的数量比HTTP1.1大了好几个数量级。

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

服务器推送：当向支持HTTP2.0的web服务器请求时，服务器会顺便把客户端需要的资源一起推送到客户端，避免客户端再次创建连接发送请求到服务器端获取，这种方式非常合适加载静态资源。

http2.0采用二进制而不是文本格式

7.4.6 HTTP和HTTPS的区别

http 和 https 都是基于 TCP 协议，但是 http 是使用明文传输，通讯内容可能被窃听和篡改，客户端也无法验证通讯方的身份，无法保证数据发送到正确的机器上；https 是在 http 的基础上加入了 SSL/TLS，可看成是添加了加密和认证机制的http，使用对称加密、非对称加密、证书等技术进行进行客户端与服务端的数据加密传输，最终达到保证整个通信的安全性。

端口不同：http 使用的是80端口，https 使用的443端口

资源消耗：和 http 通信相比，https通信会由于加解密处理消耗更多的CPU和内存资源