计算机网络面经考点整理

由于互联网公司的特性，他们更加关注日常开发所涉及到的传输层和应用层
所以在面试过程中重点准备传输层和应用层中所涉及到的知识点。

网络层

IP协议的首部结构

1. 版本。指 IP 协议的版本，目前广泛使用的版本号为4。
2. 首部长度。
3. 总长度。指首部和数据之和的长度。
4. 标识。 它是一个计数器，每产生一个数据报就加1，并赋值给标识字段。当一个数据报的长度超过网络的 MTU 时，必须分片，此时每个数据报片都复制一次标识号，以便能正确重装成原来的数据报。
5. 标志。标志字段的最低位为 MF，MF=0表示这是最后一个分片，MF=1表示后面还有分片。标志字段中间的一位是 DF，DF=0时允许分片，DF=1时不允许分片。
6. 片偏移。它指出较长的分组在分片后，某片在原分组中的相对位置。
7. 生存时间(TTL) 。数据报在网络中可通过的路由器数的最大值，标识分组在网络中的寿命，以确保分组不会永远在网络中循环。路由器在转发分组前，先把TTL 减1。若 TTL 被减为0，则该分组必须丢弃。
8. 协议。占8位。指出此分组携带的数据使用何种协议，即分组的数据部分应上交给传输层哪个协议进行处理，如 TCP 、UDP等。其中值为6表示 TCP，值为17表示UDP。
9. 首部校验和。用于校验分组的首部。
10. 源地址字段。标识发送方的IP 地址。
11. 目的地址字段。标识接收方的IP 地址。

传输层

传输层概述

传输层的作用

传输层为它上面的应用层提供通信服务。在OSI七层参考模型【应用层、表示层、会话层、传输层、网络层、数据链路层、物理层】中，传输层是面向通信的最高层，也是用户功能的最底层。

传输层复用和分用的含义

复用：在发送端，不同的应用进程都可使用同一个传输层协议传送数据
分用：在接收端，传输层根据端口号，将数据正确交付到目的应用进程

传输层和网络层的区别

网络层提供的是主机之间的逻辑通信，而传输层提供应用进程之间的逻辑通信。
网络层只对报文头部进行差错检测，而传输层对整个报文进行差错检测。

UDP 和TCP

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

UDP	TCP
UDP是面向报文的：UDP的基本传输单位是是用户数据报。发送端的UDP 对应用层交下来的报文，在添加首部后就向下交付给网络层。接收端的UDP 对 IP 层交上来 UDP 数据报，在去除首部后就原封不动地交付给上层应用进程。	TCP是面向字节流的：TCP的基本传输单位是TCP报文段。虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。
UDP是无连接的：连接双方在进行通信前，不需要建立连接。不需要连接等待，传输效率高。	TCP是有连接的：连接双方在进行通信前，需进行三次握手建立连接。需要连接等待，传输效率相对较低。
UDP是不可靠的：它是使用最大努力交付，不保证每一个数据报都送达。	TCP是可靠的：TCP发送的数据无差错、不丢失、不重复且有序。
UDP支持一对一、一对多、多对一、多对多的通信模式。UDP不提供全双工通信	TCP仅支持一对一通信。TCP提供全双工通信，允许通信双方的应用进程在任何时候都能发送数据，为此TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。
UDP首部开销只有8字节	TCP首部开销至少有20字节
UDP没有流量控制	TCP有流量控制
UDP没有拥塞控制	TCP有拥塞控制

UDP 和 TCP 的适用场景

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

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

UDP对应的协议：
DNS：域名解析服务，将域名地址转换为IP地址，使用53号端口；
SNMP：网络管理协议，用来管理网络设备，使用161号端口；
TFTP：简单文件传输协议，提供不复杂、开销不大的文件传输服务，使用 69 端口；
NFS：远程文件服务器
RIP：路由信息协议
DHCP：动态主机配置协议
IGMP：网际组管理协议

TCP对应的协议：
FTP：文件传输协议，使用21端口。上传下载文件，都要用到FTP服务
Telnet：远程终端接入，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务。
SMTP：邮件传送协议，用于发送邮件，使用25端口
POP3：邮件传送协议，POP3用于接收邮件。使用110端口
HTTP：万维网超文本传输协议，是从Web服务器传输超文本到本地浏览器的传送协议

UDP协议的首部结构

1. 源端口。源端口号。
2. 目的端口。目的端口号。
3. 长度。UDP 整个数据报的长度
4. 校验和。检测 UDP 整个数据报在传输中是否有错。有错就丢弃。

TCP协议的首部结构

一个 TCP 报文段分为首部和数据两部分。其首部的前20字节是固定的，后面有根据需要而增加的选项，选项部分长度不定，最多40字节。因此TCP头部在20-60字节之间。

1.源端口和目的端口。
端口是传输层与应用层的服务接口，源端口和目的端口指发送方应用程序的端口和目的方应用程序的端口号，通过套接字（IP 地址:端口号）就可以确定一个进程地址。

2.序号（Sequense Number，SN）。☆
在一个TCP连接中，传送的字节流中的每一个字节都按顺序编号。该字段表示本报文段所发送数据的第一个字节的序号。（初始序号称为 Init Sequense Number, ISN。ISN 是动态生成的，并非固定，因此每个连接都将具有不同的 ISN。如果 ISN 是固定的，攻击者很容易猜出后续的确认号ack）

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

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

5.保留字段
占6位，应置为 0，保留为今后使用

6.6个控制位☆
用于说明该报文段的性质

紧急位URG
当 URG = 1 时，表明此报文段中有紧急数据，是高优先级的数据，应尽快发送，不用在缓存中排队。此时首部中的紧急指针有效，紧急数据的范围从数据第一个字节到紧急指针所指字节。

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

推送位PSH（Push）
当接收方收到PSH=1的报文后，会立即将数据交付给应用程序，而不会等到缓冲区满后再提交。一些交互式应用需要这样的功能，降低命令的响应时间。

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

同步位SYN
SYN在建立连接时使用。
当SYN=1，ACK=0时，表示当前报文段是一个连接请求报文。
当SYN=1，ACK=1时，表示当前报文段是一个同意建立连接的应答报文。

终止位FIN（Finish）
当 FIN = 1时，表明此报文段的发送发的数据已发送完毕，并请求释放连接。

7.窗口大小
该字段用于实现TCP的流量控制。
它表示当前接收方的接收窗口的剩余容量，发送方收到该值后会将发送窗口调整成该值的大小。发送窗口的大小又决定了发送速率，所以接收方通过设置该值就可以控制发送放的发送速率。发送方每收到一个数据报都要调整当前的发送窗口。

8.检验和
用于接收端检验整个数据包在传输过程中是否出错。

9.紧急指针
用于标识紧急数据的尾部。

10.选项字段
选项字段是可选的，且长度可变，最长40字节。
最常用的选项字段为MSS（Maximum Segment Size）：TCP 报文段中的数据字段的最大长度。

TCP连接的建立与断开

TCP三次握手过程☆

起初，服务器和客户端都为CLOSED（连接关闭）状态。

在通信开始前，双方都得创建各自的传输控制块（TCB）。服务器创建完TCB后遍进入LISTEN状态，准备接收客户端发来的连接请求。

（1）第一次握手：客户端向服务端发送一个 SYN 报文，设置 SYN = 1 表示请求建立连接，并指明客户端初始化序列号 ISN，即图中的seq = x，表示本报文所发送的第一个字节的序号。TCP规定 ，SYN = 1 的报文段不能携带数据，但要消耗掉一个序号。该报文发送完成后，客户端便进入SYN-SENT(同步已发送)状态。

（2）第二次握手：服务端收到数据包后，由 SYN = 1 知道客户端请求建立连接，如果服务端同意连接，那么就会对这个TCP 连接分配缓存和变量（缓存指的是一个字节流队列），接着返回一个确认报文：设置 SYN = 1，ACK = 1，同时指定自己的初始化序列号 ISN，即图中的 seq = y，并把客户端的 ISN + 1 作为确认号 ack 的值，表示已经收到了客户端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 x + 1。该报文发送完成后，服务端进入SYN-RCVD(同步收到)状态。

（3）第三次握手：客户端收到确认后，检查ACK是否为1，ack是否为 x +1，如果正确，则为该TCP连接分配缓存和变量，并给服务端发送一个确认报文：设置 ACK = 1，把服务端的 ISN + 1 作为 ack 的值，表示已经收到了服务端发来的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 y + 1，并指明此时客户端的序列号 seq = x + 1。该报文段可以携带数据，若不携带数据则不消耗序号。客户端发完这个报文段后便进入ESTABLISHED(已建立连接)状态，服务端收到这个报文段后也进入ESTABLISHED(已建立连接)状态。

为什么不能用两次握手进行建立连接？ ☆

（1）三次握手目的是确认双方的接收与发送能力是否正常，同步连接双方的初始化序列号 ISN，为后面的可靠性传输做准备。而两次握手只有服务端对客户端的起始序列号做了确认，但客户端却没有对服务端的初始序列号做确认，不能保证传输的可靠性。

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

如果客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达Server。本来这是一个早已失效的报文段，但Server收到此失效的连接请求报文段后：假设不采用“三次握手”，那么只要Sever发出确认，新的连接就建立了。但由于现在Client并没有发出建立连接的请求，因此不会理睬Server的确认，也不会向Server发送数据。而Server却以为新的连接已经建立，并一直等待Client发来数据，这样，Server的很多资源就白白浪费掉了。而采用“三次握手”协议，只要Server收不到来自Client的确认，就知道Client并没有要求建立请求，就不会建立连接。

SYN洪泛
SYN 洪泛是指利用 TCP 需要三次握手的特性，攻击者伪造 SYN 报文向服务器发起连接，服务器在收到报文后用 ACK 应答，但之后攻击者不再对该响应进行应答，造成一个半连接。假设攻击者发送大量这样的报文，那么被攻击主机就会造成大量的半连接，耗尽其资源，导致正常的 SYN 请求因为队列满而被丢弃，使得正常用户无法访问。

半连接队列：服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把这种状态下的请求连接放在一个队列里，我们把这种队列称之为半连接队列。当然还有一个全连接队列，完成三次握手后建立起的连接就会放在全连接队列中。

假如第一次握手可以携带数据的话，那么会放大 SYN 洪泛。如果有人要恶意攻击服务器，每次都在第一次握手中的 SYN 报文中放入大量的数据，然后疯狂重复发送 SYN 报文的话，就会让服务器开辟大量的缓存来接收这些报文，内存会很容易耗尽，从而拒绝服务。

TCP四次挥手过程☆

TCP 是全双工模式，并且支持半关闭特性，提供了连接的一端在结束发送后还能接收来自另一端数据的能力。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。

通俗的来说，两次握手就可以释放一端到另一端的 TCP 连接，完全释放连接一共需要四次握手。

（1）第一次挥手：客户端发送一个 FIN 报文，设置 FIN = 1 表示请求释放连接，指定序列号 seq = u（u 是之前传送过来的最后一个字节的序号 + 1），用于关闭客户端到服务端的数据传送。FIN 报文段即使不携带数据，也消耗掉一个序号。该报文发送完成后，客户端进入FIN_WAIT_1（终止等待1）状态；

（2）第二次挥手：服务端收到 FIN 报文后，由 FIN = 1 知道客户端请求关闭连接，则返回确认报文：设置ACK = 1，ack = u + 1，seq = v（v 的值取决于服务器发送给客户端之前的一个包确认号是多少）。该报文发送完成后，服务端进入CLOSE_WAIT（关闭等待）状态，此时TCP连接处于半关闭状态，即客户端不能向服务端发送报文，只能接收，但服务端仍然可以向客户端发送数据。客户端收到服务端的确认后，进入 FIN_WAIT2 （终止等待2）状态，等待服务端发出的连接释放报文段。

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

（4）第四次挥手：客户端收到 FIN 报文后，发送给服务端一个 ACK 报文作为应答：设置 ACK=1 ，指定序列号seq = u+1（客户端在第一次挥手后不再发送数据，所以第四次挥手时序列号为第一次挥手发送的序列号u + 1），ack = w +1。该报文发送完成后，客户端处于 TIME_WAIT状态，该状态会持续2MSL时间，若该时间段内没有B的重发请求的话，就进入CLOSED（连接关闭）状态，撤销TCB。当B收到确认应答后，也便进入CLOSED（连接关闭）状态，撤销TCB。

为什么需要 TIME_WAIT 状态?☆
TIME_WAIT 状态持续 2MSL（MSL 最大报文存活时间），约4分钟才转换成CLOSE状态。由于TIME_WAIT 的时间会非常长，因此服务端应尽量减少主动关闭连接，TIME_WAIT 的主要作用有：
1.重发丢失的 ACK 报文，保证连接可靠的关闭：
由于网络等原因，无法保证最后一次挥手的 ACK 报文一定能传送给对方，如果 ACK 丢失，对方会超时重传 FIN，主动关闭端会再次响应ACK过去；如果没有 TIME_WAIT 状态，直接关闭，对方重传的FIN报文则被响应一个RST报文，此RST会被动关闭端被解析成错误。同时，服务器就因为接收不到客户端的信息而无法正常关闭。
2.保证本次连接的重复数据段从网络中消失：
如果存在两个连接，第一个连接正常关闭，第二个相同的连接紧接着建立；如果第一个连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达，则会干扰第二连接，等待 2MSL 可以让上次连接的报文数据消逝在网络中。

TCP的传输过程

TCP可靠传输是如何实现的

1. 三次握手
2. 应答机制与超时重传：TCP接收端收到发送端的数据时，它将发送一个确认。当TCP发送端发出一个报文段后，它会启动一个定时器，等待接收端的确认报文段，如果不能及时收到一个确认，将重发这个报文段。
3. 数据包校验与丢弃重复数据：TCP会检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP会超时重发数据；对于重复数据，则进行丢弃；
4. 对失序数据包进行重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
5. 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，防止较快主机致使较慢主机的缓冲区溢出。TCP使用的流量控制协议是可变大小的滑动窗口协议。
6. 拥塞控制：网络拥塞时，减少数据的发送。

停止等待协议

停止等待协议也称ARQ(Automatic Repeat reQuest 自动重传请求)协议，是滑动窗口协议的简化版。它的发送者每次只能发送一个分组，在应答到来前必须等待。

停止等待协在请求失败时会自动重传，直到请求被正确接收为止。这种机制保证了每个分组都能被正确接收。

无差错的情况
A向B每发送一个分组，都要停止发送，保留该分组，等待B的确认应答；A只有收到了B的确认应答后才能发送下一个分组。

分组丢失和出现差错的情况
发送者拥有超时计时器。每发送一个分组便会启动超时计时器，等待B的应答。若超时仍未收到应答，则A会重发刚才的分组。计时器的超时时间要略大于报文段往返时间(Round-Trip Time,RTT) （报文段发出的时间到报文段确认到达的时间），否则会出现很多不必要的重传，降低传输效率。但超时时间也不能太长，否则当报文段丢失时， TCP 不能很快重传，导致数据传输时延大。
分组丢失：若分组在途中丢失，B并没有收到分组，因此也不会有任何响应。当A超时后也会重传分组，直到正确接收该分组的应答为止。
分组出现差错：若B收到分组，但通过检查和字段发现分组在运输途中出现差错，它会直接丢弃该分组，并且不会有任何其他动作。A超时后便会重新发送该分组，直到B正确接收为止。
综上所述：当分组丢失或出现差错的情况下，A都会超时重传分组。

应答丢失和应答迟到的情况
TCP会给每个字节都打上序号，用于判断该分组是否已经接收。
应答丢失：若B正确收到分组，并已经返回应答，但应答在返回途中丢失了。此时A也收不到应答，从而超时重传。B收到该分组后，根据序号来判断当前收到的分组是否已经接收，发现已经接收，便丢弃该分组，并向A补上确认应答。
应答迟到：若由于网络拥塞，A迟迟收不到B发送的应答，从而超时重传。B收到该分组后，根据序号来判断当前收到的分组是否已经接收，发现已经接收，便丢弃该分组，并向A补上确认应答。A收到应答后便继续发送下一个分组。但经过了很长时间后，那个失效的应答最终抵达了A，此时A可根据序号判断该分组已经接收，此时只需简单丢弃即可。

滑动窗口协议

滑动窗口协议也称连续ARQ协议，时TCP所使用的协议。它的发送者拥有一个发送窗口，发送者可以在没有得到应答的情况下连续发送窗口中的分组。这样降低了等待时间，提高了传输效率。

发送窗口
发送窗口的大小由接收窗口的剩余大小决定（仅考虑流量控制）。接收者会把当前接收窗口的剩余大小写入应答TCP报文段的头部，发送者收到应答后根据该值和当前网络拥塞情况设置发送窗口的大小。发送窗口的大小是不断变化的。

发送窗口由三个指针构成：
p1指向发送窗口的后沿，它后面的字节表示已经发送且已收到应答。
p2指向尚未发送的第一个字节。
p3指向发送窗口的前沿，它前面的字节尚未发送，且不允许发送。
p1-p2间的字节表示已经发送，但还没收到确认应答。这部分的字节仍需保留，因为可能还要超时重发。
p2-p3间的字节表示可以发送，但还没有发送的字节。

发送者每收到一个应答，后沿p1就可以向前移动指定的字节。此时若窗口大小仍然没变，前沿p3也可以向前移动指定字节。

当p2和前沿p3重合时，发送者必须等待确认应答。

接收窗口
接收窗口是接收方接收缓存的大小，接收者收到的字节会存入接收窗口rwnd,，接收者在一定时间内（一般是0.5S以内）对已经正确接收的TCP报文段进行累计确认(即同时确认这些报文段)，发送完确认应答后，接收窗口就可以向前移动指定字节。如果某些字节并未按序收到，接收者确认最后一个有序的字节，从而乱序的字节就会被重新发送。累计确认能节省流量。

补充内容
同一时刻发送窗口的大小并不一定和接收窗口rwnd一样大。
虽然发送窗口的大小是根据接收窗口的大小来设定的，但应答在网络中传输是有时间的，有可能t1时间接收窗口大小为m，但当确认应答抵达发送者时，接收窗口的大小已经发生了变化。
此外发送窗口的大小还随网络拥塞情况影响。当网络出现拥塞时，发送窗口将被调小。

TCP标准并未规定未按序到达的字节的处理方式。但TCP一般都会缓存这些字节，等缺少的字节到达后再交给应用层处理。这比直接丢弃乱序的字节要节约带宽。

TCP允许接收者在有数据要发送的时候捎带上确认应答。但这种情况一般较少，因为一般很少有两个方向都要发送数据的情况。

TCP流量控制

流量控制：让发送方的发送速率不要太快，让接收方来得及接收。因为如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。

TCP的流量控制是通过大小可变的滑动窗口来实现的。接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK报文来通知发送端，滑动窗口是接收端用来控制发送端发送数据的大小，从而达到流量控制。

注意：滑动窗口为 0 时，紧急数据仍然可以发送。例如，允许用户终止在远端机上的运行进程。

流量控制引发的死锁
当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。

持续计时器
为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。

TCP拥塞控制

拥塞控制：发送端根据网络拥塞情况对发送速率作调整，防止过多的数据注入网络中，使网络中的路由器或链路不致过载，减少分组丢失的可能性，保证分组按时到达。出现拥塞时，端点并不了解拥塞发生的细节，对通信连接的端点来说，拥塞往往表现为通信时延的增加。

发送方维持一个拥塞窗口cwnd（congestion window）的状态变量。
拥塞窗口的大小动态变化，取决于网络的拥塞程度。发送方让自己的发送窗口等于拥塞窗口（仅考虑拥塞控制）
只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。
但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。

拥塞控制的方法主要有以下几种：慢开始、拥塞避免、快重传和快恢复。
在TCP 连接建立和网络出现超时时，采用慢开始和拥塞避免算法；
当发送方接收到冗余ACK 时，采用快重传和快恢复算法。

（1）☆慢开始算法： 在TCP 开始发送报文段时，先设置cwnd=1，即一个最大报文段长度MSS，使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况)。然后每经过一个传输轮次RTT(即往返时间)，拥塞窗口 cwnd 就翻倍，即拥塞窗口 cwnd随传输轮次指数规律增长。慢开始算法可以避免一开始就往网络中注入过多的分组从而导致拥塞。
另外，为了防止拥塞窗口cwnd增长过大引起网络拥塞，设置一个慢开始门限 ssthresh 状态变量。
当 cwnd < ssthresh 时，使用上述的慢开始算法。
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法(通常做法)。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。

注意：在慢开始阶段，若拥塞窗口 cwnd 翻倍大于慢开始门限 ssthresh，即2cwnd>ssthresh， 则将拥塞窗口 cwnd 等于慢开始门限 ssthresh， 而不等于2cwnd, 即 cwnd 不能跃过 ssthresh 值。

（2）☆拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个传输轮次RTT就把发送方的拥塞窗口cwnd加1，使拥塞窗口cwnd 按线性规律缓慢增长(即加法增大)，以防止网络过早出现拥塞。

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

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

（4）快恢复：当发送方连续收到三个重复确认时，就执行“乘法减少”算法，把ssthresh门限设置为拥塞窗口cwnd的一半（预防网络发生拥塞），并将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。因为如果网络出现拥塞的话，就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞，所以此时执行拥塞避免算法。

写在最后：若同时考虑流量控制和拥塞控制，则发送窗口的大小是接收窗口rwnd和拥塞窗口cwnd两者的最小值。

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

（1）相同点：流量控制和拥塞控制的相同点都是控制丢包现象，它们都通过控制发送方发送数据的速率来达到控制效果。
（2）不同点：
　①在流量控制中，发送方发送数据的量由接收方决定，而在拥塞控制中，则由发送方自己通过检测网络状况来决定。
　②流量控制往往是指点对点的通信量的控制，是个端到端的问题(接收端控制发送端),它所要做的是抑制发送端发送数据的速率，以便使接收端来得及接收。反而，拥塞控制是让网络能够承受现有的网络负荷，是一个全局性的过程，涉及所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

应用层

应用层主要提供应用进程间的网络通信服务，完成用户请求的各种服务。

HTTP协议

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

HTTP请求响应模型
HTTP遵循请求(Request)/响应(Response)模型，这是一个标准的客户端服务器模型（B/S），即客户端（Web浏览器）向服务器发送请求，服务器处理请求并返回响应。

HTTP是一个无状态的协议。
无状态是指客户端（Web浏览器）和服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出请求，然后服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息。

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

HTTP请求格式

客户端通过发送 HTTP 请求向服务器请求对资源的访问。 HTTP 请求由三部分组成：请求行、首部行和实体主体(entity-body)，实体主体(entity-body)是可选的。

请求行
请求行是“请求方法 请求URL 协议/版本”，并以回车换行作为结尾。请求行以空格分隔。格式如下：POST /index.php HTTP/1.1。这行代码中“ GET”代表请求方法，“/index.php”表示请求URI，“HTTP/1.1代表协议和协议的版本。

请求方法(method)
最常用的方法是GET和POST
（1）GET 请求获取由 Request-URI 所标识的资源
（2）POST 请求服务器接收在请求中封装的实体，并将其作为由 Request-Line 中的 Request-URI 所标识的资源的一部分。不是幂等的，多次执行会导致多条数据被创建。
（3）HEAD 请求获取由 Request-URI 所标识的资源的响应消息报头
（4）OPTIONS 请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项
（5）PUT 请求服务器存储一个资源，并用 Request-URI 作为其标识符，是幂等的，多次操作会导致前面的数据被覆盖。
（6）DELETE 请求服务器删除由 Request-URI 所标识的资源
（7）TRACE 请求服务器回显收到的请求信息，主要用于测试或诊断

GET和 POST 请求的区别
（1）功能：GET一般用来从服务器上面获取资源，POST一般用来更新服务器上面的资源。
（2）幂等性：GET 是幂等的，POST 为非幂等的。
（3）安全性：GET 请求的参数会明文附加在URL之后，而 POST 请求提交的数据则被封装到请求体中，相对更安全。
（4）传输数据量的大小：GET请求允许发送的数据量比较小，由于GET请求的参数会明文附加在URL之后，而浏览器对URL的长度有限制，所以提交的数据量不能太大。而post请求提交的数据量则是没有大小限制的。
（5）参数的数据类型：GET只接受ASCII字符，而POST没有限制。
（6）GET在浏览器回退时是无害的，而POST会再次提交请求。
（7）GET请求可以被缓存，可以被保留在浏览器的历史记录中；post请求不会被缓存，不会被保留在浏览器的历史记录中。
注意：在 HTML 文档中，书写 GET 和 POST，大小写都可以，但在 HTTP 协议中的 GET 和 POST 只能是大写形式。

首部行
由一个首部字段名，冒号（:）和值三部分组成。首部字段名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行结束处，使用至少一个回车换行CRLF。

1.Transport 头域

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

2.Client 头域

Accept：告诉服务器能够发送哪些媒体类型
Accept-Charset：告诉服务器能够发送哪些字符集
Accept-Encoding：告诉服务器能够发送哪些编码方式
Accept-Language：告诉服务器能够发送哪些语言
User-Agent：将发起请求的应用程序名称告知服务器
Authorization：包含了客户端提供给服务器，以便对其自身进行授权认证的数据

3.Cookie/Login 头域

Cookie:将cookie的值发送给服务器

4.Entity头域

Content-Type：实体主体的对象类型
Content-Length：实体主体的长度

5.Miscellaneous 头域

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

6.Cache 头域

Pragma：防止页面被缓存，即Pragma: no-cache
在HTTP/1.0版本中，只实现了Pragema:no-cache, 没有实现Cache-Control
在HTTP/1.1版本中，它和Cache-Control:no-cache作用一模一样
Cache-Control：指定Response-Request遵循的缓存机制
Cache-Control:Public 可以被任何缓存所缓存
Cache-Control:Private 内容只缓存到私有缓存中
Cache-Control:no-cache 所有内容都不会被缓存

HTTP响应格式

在接收和解释请求消息后，服务器会返回一个 HTTP 响应消息。与 HTTP 请求类似，HTTP 响应也是由三个部分组成，分别是：状态行、首部行和实体主体(entity-body)，实体主体(entity-body)是可选的。

状态行
状态行由协议版本、状态码及原因短语组成，各元素之间以空格分隔，结尾时回车换行符，例如HTTP/1.1 200 OK (CRLF)

状态码(status-code)和原因短语(reason-phrase)
（1）1xx：指示信息——表示请求已经接受，继续处理
（2）2xx：成功——表示请求已经被成功接收、理解、接受。
　 　200 OK ：客户端请求成功；
　 　204：（请求处理成功，但是没有资源返回）
（3）3xx：重定向——要完成请求必须进一步处理
　 　301 Moved Permanently：永久性转移，请求的资源已经被分配到了新的地址
　 　302 Found：暂时重定向
　 　304 Not Modified：没修改，已缓存。
（4）4xx：客户端错误——客户端请求有错误或请求无法实现。
　 　400 Bad Request：客户端请求有语法错误，不能被服务器所理解
　 　401 Unauthorized：客户端未经授权
　 　403 Forbidden：没有权限访问该资源
　 　404 Not Found：请求资源不存在
　 　405 Method Not Allowed：不支持该请求方法，如果服务器支持GET，客户端用POST请求就会出现这个错误码
（5）5xx：服务器端错误——服务器未能实现合法的请求。
　 　500 Internal Server Error ：服务器发生不可预期的错误。
　 　502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
　 　503 Server Unavailable：服务不可用，一段时间后可能恢复正常。
　 　504 Gateway Time-out：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应

首部行
由一个首部字段，冒号（:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行结束处，使用至少一个回车换行CRLF。

1.Cache头域

Date：日期和时间标志，说明报文是什么时间创建的
Expires：指明文档的过期时间，超过时间就不再缓存

2.Cookie/Login 头域

P3P：用于跨域设置Cookie, 这样可以解决iframe跨域访问cookie的问题
Set-Cookie：把cookie发送到客户端浏览器，以便服务器对客户端进行标识。

3.Entity实体头域

ETag：与此实体相关的实体标记
Last-Modified：这个实体最后一次被修改的日期和时间
Content-Type：实体主体的对象类型
Content-Length：实体主体的长度
Content-Encoding：实体主体的编码方式
Content-Language：实体主体的语言

4.Miscellaneous 头域

Server：服务器应用程序软件的名称和版本
X-Powered-By：表示网站是用什么技术开发的

5.Transport头域

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

6.Location头域

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

HTTP工作流程

一次HTTP操作称为一个事务。假设客户端浏览器请求这个页面：http://mail.163.com/index.html，则工作整个过程如下：

（1）解析统一资源标识符（URI），获取URl中包含的域名；
　从URI（http://mail.163.com/index.html）中解析出协议名（http）、域名（mail.163.com）等部分。

（2）通过域名系统DNS (Domain Name System)解析域名，得对应主机的IP地址；

DNS服务器大致分为三种类型：根域名服务器、顶级域名服务器和授权域名服务器。
根域名服务器在全球有13台，IP地址固定。尽管我们将这13 个根域名服务器中的每个都视为单个服务器，但每个“服务器”实际上是冗余服务器的集群，以提供安全性和可靠性。
顶级域名服务器主要负责诸如com(公司)、org(非营利性组织)、net(网络服务机构)、edu、gov (国家或政府部门)等顶级域名。

根域名服务器存储了所有顶级域名服务器的 IP 地址，顶级域名服务器存储了权威域名服务器的 IP 地址，授权域名服务器存储了主机的 IP 地址。此外，本地域名服务器是具有缓存功能的，通常两天内的记录都会被缓存。

DNS系统查询域名对应的 IP 的具体步骤：
① 操作系统先查本地 hosts文件中是否有记录，如果有，则直接返回相对应映射的IP地址。
② 如果本地 hosts 文件中没有配置，则主机向自己的本地域名服务器发送查询报文，如果本地域名服务器缓存中有，将直接返回结果。
③ 如果本地域名服务器缓存中没有，则本地域名服务器从内置的根域名服务器中任选一个发送查询请求。根域名服务器将相对应的顶级域名服务器的 IP 地址列表返回。
④ 本地域名服务器任选一个顶级域名服务器发送查询请求，顶级域名服务器将相对应的授权域名服务器的 IP 地址列表返回。
⑤ 本地域名服务器任选一个授权域名服务器发送查询请求，授权域名服务器将相对应主机 IP 地址返回。
⑥ 本地域名服务器将主机 IP 地址保存到本地缓存，同时返回给主机。

（3）浏览器得到域名对应的IP地址之后，和服务器三次握手建立TCP链接；

（4）TCP链接建立起来后，浏览器向服务器发送HTTP请求。如果 html文件在缓存里，浏览器则直接返回， 如果没有，则去后台拿。

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

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

③在协商缓存阶段，可以向服务器发送header带有If-Modified-Since的请求。If-None-Match和ETag一起工作，工作原理是在HTTP Response中添加ETag信息， 当用户再次请求该资源时，将在HTTP Request 中加入If-None-Match信息(ETag的值)，如果服务器验证资源的ETag没有改变（该资源没有更新），将返回一个304状态告诉客户端使用本地缓存文件，否则将返回200状态和新的资源和Etag，这样的机制可以提高网站的性能。

④在协商缓存阶段，也可以向服务器发送header带有If-Modified-Since的请求，If-Modified-Since把浏览器端缓存页面的最后修改时间发送到服务器去，服务器会把这个时间与服务器上实际文件的最后修改时间进行对比，如果时间一致，那么返回304，客户端就直接使用本地缓存文件，如果时间不一致，就会返回200和新的文件内容，客户端接到之后，会丢弃旧文件，把新文件缓存起来，并显示在浏览器中。

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

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

（7）服务器断开TCP连接
若HTTP使用短连接，即TCP的短连接，则客户端与服务端每进行一次请求操作，就建立一次TCP连接，收到服务器响应后，就断开连接。
若HTTP使用长连接，即TCP的长连接，则客户端和服务端建立TCP连接后，它们之间的连接会持续存在，不会因为一次HTTP请求后关闭，后续的请求也是用这个连接进行通信。使用长连接的HTTP协议，会在浏览器或者服务器的头信息加入：Connection:keep-alive。从http1.1开始就默认使用长连接。

长连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。但在长连接下，客户端一般不会主动关闭连接，如果客户端和服务端之间的连接一直不关闭的话，随着连接数越来越多，会对服务端造成压力。所以像Web网站这种并发量大，但是每个用户无需频繁操作的场景，一般都使用短连接，因为长连接对服务端来说会耗费一定的资源。而长连接多用于频繁请求资源，而且连接数不能太多的情况，例如数据库的连接用长连接。

HTTP1.1和HTTP2.0的区别

（1）多路复用，做到同一个连接并发处理多个请求：HTTP2.0 使用了多路复用的技术，做到同一个连接并发处理多个请求，并发请求的数量比HTTP1.1大了好几个数量级。
（2）支持首部压缩：HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
（3）服务器推送：当向支持HTTP2.0的web服务器请求时，服务器会顺便把客户端需要的资源一起推送到客户端，避免客户端再次创建连接发送请求到服务器端获取，这种方式非常合适加载静态资源。
（4）http2.0采用二进制而不是文本格式

HTTP存在的问题

通信使用明文不加密，通信内容可能被窃听；
无法验证报文的完整性，数据内容可能被篡改
不验证通信方身份、可能遭到伪装，无法保证数据发送到正确的机器上；
为了解决上述几个问题，那么就引入了https协议。

HTTPS协议

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

对称加密：加密和解密都使用同一个密钥，包括DES、3DES、AES等，其中AES综合考虑最优。这种方式存在如何安全地将密钥发送对方的问题。

非对称加密：使用两个密钥，公钥加密则需要私钥解密，私钥加密则需要公钥解密，包括RSA、DSA、ECC等，其中RSA或ECC综合考虑最优。非对称加密不需要发送用来解密的私钥，所以可以保证安全性。

非对称加密比对称加密慢很多，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

CA机构准备阶段☆

1.服务器生成公钥S.pub和私钥S.pri。私钥S.pri自己保留，公钥S.pub发送给CA进行签名认证。
2.CA机构（证书发布机构）生成公钥C.pub和私钥C.pri。用私钥C.pri来对服务器的公钥S.pub进行加密；用散列函数（即所用的签名算法，包括SHA-1、MD5等，其中MD5综合考虑最优）计算公开的明文信息摘要得到hash值，用私钥C.pri对hash值进行加密，得到签名。
3.CA机构将证书发布机构、加密后的服务端公钥S.pub、数字签名、所用的签名算法、有效期等打包成证书，返回给服务器。
4.浏览器内置包含公钥C.pub的证书，称之为根证书。

HTTPS的通讯过程☆

1.客户端发起HTTPS请求

2.服务端传送证书

3.客户端验证证书，获得公钥S.pub，传送加密随机值
①客户端从证书中读取证书的CA机构，在浏览器中查找到对应的CA机构的根证书，获得此CA机构的公钥C.pub。
②客户端用公钥C.pub对签名进行解密，获得hash值；客户端采用相同的散列函数计算公开的明文信息摘要，获得hash值；将两个hash值做对比(防止信息被修改)， 对比结果一致，则证明证书没有问题。
③ 客户端验证证书中的其他信息。
④客户端用公钥C.pub对加密后的公钥S.pub进行解密，获得公钥S.pub；客户端生成一个随机值，用公钥S.pub对随机值进行加密，传送加密随机值Z给服务器端。

4.服务端解密信息
服务端得到加密随机值。用私钥S.pri将它进行解密，得到了客户端传过来的随机值Z

5.服务端和客户端的通信
服务端通过随机值Z加密内容，发送给客户端，客户端通过随机值Z解密；
客户端通过随机值Z加密内容，发送给服务端，服务端通过随机值Z解密；

准备阶段必不可少的原因

CA证书是为了确保服务端的公钥是准确无误、没有被修改过的。

如果没有CA证书，攻击者可以按下面的方式进行攻击：
1.截取服务器发送的包含公钥的包
2.自己生成一对公私钥
3.将自己的公钥代替服务器的公钥发给客户端，让客户端使用
4.截取客户端发送的加密随机值
5.用自己的私钥进行解密，获得随机值Z
6.通过服务器的公钥加密随机值Z并发给服务器。

这样攻击者就可以获得服务端和客户端之间通信的对称密钥Z，并从而获得通信内容

HTTP和HTTPS的区别☆

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

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

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