[toc]

计算机网络体系结构

OSI七层网络结构

应用层 : 为特定应用程序提供数据传输服务，例如 HTTP、DNS 等协议。数据单位为报文。

表示层 : 数据压缩、加密以及数据描述

会话层 : 建立及管理会话

运输层 : 为进程提供通用数据传输服务。 主要包括TCP和UDP两种协议。

网络层 : 为主机提供数据传输服务。 主要任务是将上层传下来的报文段封装分组传输。主要协议为IP协议。针对主机与主机之间的数据传输。

数据链路层 : 将网络层传下来的报文段数据封装成帧。

物理层 : 将帧转换为数字信号或模拟信号放到传输介质上传输

链路层和网络层的区别

IP层主要负责两个没有直连的网络之间的通信，而MAC层主要负责两个直连的网络之间的连接。

在网络中数据包传输中，源IP地址和目标IP地址在传输过程中是不会变化的，只有 源 MAC 地址和目标 MAC 一直在变化。

ARP毒化

ARP毒化的运作原理是由攻击者发送假的ARP数据包到网上，尤其是送到网关上。其目的是要让送至特定的IP地址的流量被错误送到攻击者所取代的地方。因此攻击者可将这些流量另行转送到真正的网关或是篡改后再转送。攻击者亦可将ARP数据包导到不存在的MAC地址以达到阻断服务攻击的效果 .

最理想的防制方法是网上内的每台计算机的ARP一律改用静态的方式，不过这在大型的网上是不可行的，因为需要经常更新每台计算机的ARP表。

另外一种方法，例如DHCP snooping，网上设备可借由DHCP保留网络上各计算机的MAC地址，在伪造的ARP数据包发出时即可侦测到。此方式已在一些厂牌的网上设备产品所支持。

CSRF攻击

链路层和网络层

DHCP

应用层协议

IP地址和mac地址有什么作用？

mac地址是硬件地址，用来定义网络设备的位置，一般没有两个设备存在相同的mac地址。

ip地址是ip协议提供的统一格式的地址，为互联网上每个网络和主机分配一个逻辑地址，屏蔽物理地址的差异。

ARP协议

在数据链路层上，向目标地址发送数据包时，需要知道目标的mac地址，ARP协议，就是用来定位下一个接收数据的网络设备对应的mac地址。

ARP协议工作机制：首先广播一个arp请求包，其中包含它想要了解的mac地址的主机ip，当收到包的主机发现其中的ip与自己的ip一致时，则将自己的mac地址塞入包中作为响应包发送回请求主机

ICMP协议

ICMP是用来确认网络是否正常连接，以及遇到异常时的问题诊断的协议。它能够确认ip包是否到达不妙地址，以及ip包被废弃的原因。得到这些信息从而改善网络设置。

MTU (最大传输单元)

MTU是链路层以太网对数据帧的传输存在一个限制，最大值一般为1500字节或1492字节，如果ip层所传的数据报比链路层MTU还大，则需要进行分片，把数据包分为若干片，所有的分片都要比MTU小。

TCP与 UDP

TCP和UDP的区别

• 连接：TCP 是面向连接的协议，TCP 必须通过三次握手建立连接，而 UDP 是无连接的协议。
• 字节流和报文：TCP 是字节流的协议， 无记录边界。UDP 发送的每个数据报是记录型的数据报， 所谓的记录型数据报就是接收进程可以识别接收到的数据报的记录边界。
• 可靠性：TCP 提供交付保证，这意味着一个使用 TCP 协议发送的消息是保证交付给客户端的，如果消息在传输过程中丢失,那么它将重发。UDP 是不可靠的,它不提供任何交付的保证，一个数据报包在运输途中可能会丢失。
• 速度：TCP 速度比较慢， 而 UDP 速度比较快， 因为 TCP 必须创建连接， 以保证消息的可靠交付和有序性。
• 报文大小：TCP 数据报的报头大小最少是 20 字节，UDP 数据报的报头固定是 8 个字节。TCP 报头中包含序列号， ACK 号， 数据偏移量， 保留， 控制位， 窗口， 紧急指针， 可选项， 填充项， 校验位， 源端口和目的端口。 而 UDP 报头只包含长度， 源端口号， 目的端口，和校验和。
• 流量控制和拥塞控制：TCP 有流量控制和拥塞控制。UDP 没有流量控制和拥塞控制。
• 单播和多播：TCP 只能单播，而 UDP 可以广播和组播

TCP如何实现可靠传输

1.使用三次握手四次挥手，保证连接的建立

2.使用序列号，对每个报文段进行标号保证到达对端的时候数据有序

3.使用确认应答机制，保证每个报文段都被对方接收到。

4.使用超时重传机制，若迟迟未收到对方的确认应答，则认为发送失败，重新发送。

5.使用校验和，发送报文段后，需要对报文段进行检查是否在发送过程中出现错误。

6.拥塞控制，

​ 慢启动，定义拥塞窗口，最开始为1，每次接收到确认应答后，拥塞窗口乘二

​ 拥塞避免，设置慢启动阈值，若达到阈值，每次拥塞窗口以加法增长，避免拥塞。

​ 快重传。要求对方接收到数据后立刻发送应答报文，而不是捎带发送，若发送方收到三个充分的ack，则直接进行重传

​ 快恢复，当发送端收到三个重复的应答后，将拥塞窗口设置为当前的一半，然后用拥塞避免算法重新启动。

7. 流量控制

   TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据。 这将防止较快主机致使较慢主机的缓冲区溢出。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

三次握手

三次握手是 TCP 建立连接的过程，握手需要在客户端和服务器之间交换三个报文段：

• 第一次握手：服务器 B 处于监听状态，客户端 A 向 B 发送请求连接报文，报文首部标志位 SYN 设为 1，选择初始序号 x；A 进入同步已发送状态。
• 第二次握手：B 收到 A 的请求连接报文，如果同意连接，则返回确认，确认报文标志位 SYN 和 ACK 设为 1，确认号为 x+1，选择初始序号 y；B 进入同步收到状态。
• 第三次握手：A 收到 B 发出的确认后，还需要再次确认，报文 ACK 设为 1，确认号 y+1，序号为 x+1；A 进入连接建立状态。可以携带数据，不携带则不消耗序号，也就是说下个报文序号仍是 x+1。
• 最后 B 收到 A 的确认报文后也进入连接建立状态。

为什么需要第三次握手

1. 为了防止失效的连接请求到达服务器，让服务器错误打开连接。

2. 为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤

3. 如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认

三次握手如果第三次ack包丢失怎么办

如果第三次握手ack包丢失，那么服务端会启动超时重传机制，过久未收到反馈，会重新发送第二次握手的确认包，以便客户端重新发送ack，如果重传指定次数后，仍然没有接收到ack，则服务端认为发送失败，自动关闭其连接。

四次挥手

四次挥手是 TCP 连接释放的过程，通信双方都可以释放连接：

• 第一次挥手：主机 A 向主机 B 发送连接释放报文，报文首部 FIN 设为 1，并且序号为 u，u 是已发送数据的最后一个字节序号加 1。A 进入终止等待 1 状态。
• 第二次挥手：B 收到连接释放报文后进行确认，报文首部 ACK 设为 1，确认号为 u+1，序号为 v，v 是已发送数据的最后一个字节序号加 1。同时 B 进入关闭等待状态；这个时候的 TCP 连接处于半关闭状态，也就是，A 已经没有数据需要发送，但 B 可能还会有数据。A 收到确认后，进入终止等待 2 状态，等待 B 发送连接释放报文。
• 第三次挥手：B 没有数据发往 A 了，则将发送连接释放报文，首部 FIN 设为 1，序号为 w，确认号还是 u+1，同时 B 进入最后确认状态。
• 第四次挥手：A 收到 B 的连接释放报文后，发出确认，ACK 为 1，确认号为 w+1，序号为 u+1，同时进入时间等待状态。需要等待 2MSL 后，才进入关闭状态。

保活计时器

TCP 设有一个保活计时器，如客户机和服务器建立连接后，客户机出现故障，此时服务器就无法收到来自客户机发送的数据，所以可以使用保活计时器，服务器每收到一次客户机数据，就重新设置保活计时器，其时间的设置通常为 2 小时，超时后，每隔 75 秒发送探测报文段，连续 10 个客户机都无响应，则可以关闭该连接。

TCP校验和步骤

• 填上伪首部，对齐用0填充校验和字段和数据字段
• 将伪首部+首部+数据部分采用二进制反码求和
• 将和求反码填入校验和
• 在接收端同样采用二进制反码求和
• 结果全为1，则无错误

若接收端发现校验和出现错误，则直接将数据包丢弃。

流量控制

窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；

接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {1, 2, 4, 5}，其中 {1, 2} 按序到达，而 {4, 5} 就不是，因此只对字节 {1, 2} 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

发送窗口用来暂时存放：

• 发送应用程序传送给发送方 TCP 准备发送的数据；
• TCP 已发送出但尚未收到确认的数据。

接收窗口用来暂时存放：

• 按序到达的、但尚未被接收应用程序读取的数据；
• 不按序到达的数据。

拥塞控制

拥塞控制是防止过多的数据注入到网络中，避免路由器或链路过载。TCP 的拥塞控制是基于窗口的，发送方维护一个拥塞窗口的状态变量，拥塞窗口等于发送窗口。拥塞控制算法有：慢开始，拥塞避免，快重传和快恢复算法。

1. 慢开始算法：当主机开始发送数据，拥塞窗口从 1 开始，每经过一个传播轮次（传播轮次是把拥塞窗口所允许发送的报文段都连续发送出去，并且受到对最后一个字节的确认所经历的时间），拥塞窗口大小加倍。
2. 拥塞避免算法：为避免拥塞窗口增加过大，需要慢开始门限：当拥塞窗口小于慢开始门限时，使用慢开始算法；大于慢开始门限时，使用拥塞避免算法。拥塞避免算法是让拥塞窗口线性增加，每个传播轮次让拥塞窗口加 1。
3. 快重传算法：可以让发送方尽早知道个别报文段的丢失，它要求接收方收到数据立即回复对已收到报文的确认，如果发送方一连收到 3 个重复确认，说明报文段丢失，立即重传。
4. 快恢复算法：重传后，发送方知道只是个别报文的丢失，所以执行快恢复算法，调整慢开始门限值为原来的一半，并且设拥塞窗口等于慢开始门限，并执行拥塞避免算法。

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

• 拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不会过载
• 流量控制往往是点对点通信量的控制，是一个端到端的问题，流量控制要做的是抑制发送端发送数据的速率，以便接收端来得及接收。

为什么等待 2MSL 时间

MSL是最长报文段寿命，设置的目的是：

1. 保证 A 发送的最后一个确认报文段到达 B。因为这个报文段可能丢失，如果丢失后，B 会重传报文，A 只有在时间等待状态才能收到并重传确认报文，最后 A 和 B 都正常进入关闭状态。如果没有 TIME-WAIT 状态，而是立即释放连接，B 就无法正常进入关闭状态。
2. 确保已失效的连接请求报文在网络中消失。A 发送最后一个 ACK 报文段后，经过 2MSL 后本连接持续的时间内所产生的所有报文段都从网络中消失，这样下次新的连接就不会出现旧的连接请求报文。

采用滑动窗口可能会出现什么问题，怎么解决的。

所谓流量控制就是让发送方发送速率不要过快，让接收方来得及接收。利用TCP报文段中的窗口大小字段来控制发送方的发送窗口不大于接收方发回的窗口大小就可以实施流量控制。

考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。

解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。

粘包

TCP 报文粘连就是，本来发送的是多个 TCP 报文，但是在接收端收到的却是一个报文，把多个报文合成了一个报文。 "粘包"可发生在发送端，也可发生在接收端。 在流传输中出现，UDP不会出现粘包， 因为它有消息边界（两段数据间是有界限的） 。

TCP 报文粘连的原因：

1. 由 Nagle 算法造成的发送端的粘包
   Nagle 算法产生的背景是， 为了解决发送多个非常小的数据包时（比如 1 字节） ， 由于包头的存在而造成巨大的网络开销。 简单的讲， Nagle 算法就是当有数据要发送时， 先不立即发送， 而是稍微等一小会， 看看在这一小段时间内， 还有没有其他需要发送的消息。当等过这一小会以后， 再把要发送的数据一次性都发出去。 这样就可以有效的减少包头的发送次数。
2. 接收端接收不及时造成的接收端粘包
   TCP 会把接收到的数据存在自己的缓冲区中,然后通知应用层取数据.当应用层由于某些原因不能及时的把 TCP 的数据取出来,就会造成 TCP 缓冲区中存放了几段数据， 产生报文粘连的现象。

TCP 报文粘连的解决方法：

1. 关闭 Nagle 算法。 在 scoket 选项中， TCP_NODELAY 表示是否使用 Nagle 算法。
2. 接收端尽可能快速的从缓冲区读数据。
3. 可以在发送的数据中，添加一个表示数据的开头和结尾的字符，在收到消息后， 通过这些字符来处理报文粘连

TCP 三次握手漏洞

SYN 泛洪攻击是 DDoS 攻击的方式之一，这是一种利用 TCP 协议缺陷，发送大量伪造的 TCP 连接请求，从而使得被攻击方资源耗尽的攻击方式。在 TCP 连接的三次握手中， 假设一个用户向服务器发送了 SYN 报文后突然宕机，那么服务器在发出 SYN+ACK 应答报文后是无法收到客户端的 ACK 报文，这种情况下服务器端一般会不停地重试直到超时；如果恶意发送大量伪造 IP 地址的攻击报文，发送到服务器，服务器将为了维护一个非常大的半连接队列而消耗资源。服务器端也将忙于处理攻击者伪造的 TCP 连接请求而无暇理睬客户的正常请求 ，此时从正常客户的角度看来，服务器失去响应。

解决方法：

1. 缩短重试时间：由于 SYN Flood 攻击的效果取决于服务器上保持的 SYN 半连接数，所以通过缩短从接收到 SYN 报文到确定这个报文无效并丢弃该连接的时间， 例如设置为 20 秒以下，可以成倍的降低服务器的负荷。
2. 设置 Cookie：给每一个请求连接的 IP 地址分配一个 Cookie， 如果短时间内连续受到某个 IP 的重复 SYN 报文， 就认定是受到了攻击
3. 缓存：收到 SYN 报文时不急着去分配资源，而是先回应一个 ACK 报文，并将这种半开连接保存在缓存中，直到收到正确的 ACK 报文再去分配资源
4. 硬件***：泛洪攻击很容易就能被***拦截

TCP如何实时监测断线情况

• 心跳包机制， 客户端每隔一定时间间隔发送心跳包，若没收到回应，则认为断线，立即关闭socket
• 利用tcp_keepalive机制，通过设定tcp选项设定 keepalive_probes 探测次数， keepalive_time超时间隔， keepalive_intvl 探测间隔，来检测断线

tcp接收数据不完整如何解决

当发送的数据过大时，我们不能直接进行处理，要等到所有的数据接收完成再一起处理，在每个tcp报文段加上一个数据长度，根据传输数据的长度进行处理，注意将最后报文填充部分的'\0'清理掉。

既然 IP 层会分片，为什么 TCP 层还需要 MSS 呢？

如果在 TCP 的整个报文（头部 + 数据）交给 IP 层进行分片，会有什么异常呢？

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

因为 IP 层本身没有超时重传机制，它由传输层的 TCP 来负责超时和重传。 当接收方发现 TCP 报文（头部 + 数据）的某一片丢失后，则不会响应 ACK 给对方，那么发送方的 TCP 在超时后，就会重发「整个 TCP 报文（头部 + 数据）」。 因此，可以得知由 IP 层进行分片传输，是非常没有效率的。

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

udp如何实现可靠性传输

依靠应用层协议来实现确认机制，重传机制，窗口确认机制等

在不调整链路层的情况下怎么提高udp的可靠性（发标记的冗余包）

HTTP

HTTP1.0 与HTTP1.1的区别

HTTP 1.1 引入 5 个特性

默认持久连接

HTTP/1.1 默认使用持久连接，TCP 连接默认不关闭，可以被多个请求复用。而 HTTP/1.0 默认使用短连接，要建立长连接， 可以在请求消息中声明 Connection:Keep-Alive。

管道机制

客户端可以同时发送多个请求，而不用收到前一个响应之后再发出下一个请求，但服务器必须按照接收到客户端请求的先后顺序依次返回响应结果，以保证客户端能够区分出每次请求的响应内容

分块传输数据

HTTP/1.1 引入了分块传输方法。该方法使发送方能将消息实体分割为任意大小的组块，并发送它们。在每个组块前面，都加上了该组块的长度，使接收方可确保自己能够完整地接收到这个组块。最后发送方会发送长度为 0 的组块，表示消息发送完毕。

状态码 100 Continue

HTTP/1.1 加入了新的状态码 100 Continue，如果服务器因为权限拒绝了请求，就返回状态码 401；如果服务器接收此请求就返回状态码 100，客户端就可以继续发送带实体的完整请求了。

Host 域

在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，这个 IP 地址上只有一个主机。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个 IP 地址。所以 HTTP1.1 在请求消息头中多了一个 Host 域。

HTTP2.0 相对HTTP1.1在性能上的改进

1. 头部压缩

   HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会 帮你消除重复的部分。

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

2. 二进制格式

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

3. 数据流

   HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必 须要对数据包做标记，指出它属于哪个回应。 每个请求或回应的所有数据包，称为一个数据流（ Stream ）。每个数据流都标记着一个独一无二的编 号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数 客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。

4. 多路复用

   HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟， 大幅度提高了连接的利用率。 举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗 时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

Get 和 Post 的区别

• 使用范围：GET 一般用于获取或者查询资源信息，它是幂等的（对同一个 URL 的多个请求返回同样的结果） 和安全的（没有修改资源的状态），而 POST 一般用于更新资源信息。
• 传递数据：
  • 采用 GET 方法时，客户端把要发送的数据添加到 URL 后面，HTTP 协议没有对 URL 长度进行限制，但浏览器和服务器对 URL 的长度存在限制，所以传递的数据量有限；并且数据是明文出现在 URL 上面，所以一般只用于传输不敏感的信息。
  • 而 POST 把要传递的数据放到 HTTP 请求报文的请求体中；HTTP 协议也没有进行大小限制，起限制作用的是服务器的处理能力，传送的数据量比 GET 方法更大些； 由于传递的数据在消息体中， 安全性比 GET 高些
  • GET 请求的数据会被浏览器缓存起来，会留下历史记录；而 POST 提交的数据不会被浏览器缓存， 不会留下历史记录

HTTP请求报文格式与响应报文格式

请求报文主要由 4 部分组成：

• 请求行：由 3 部分组成：请求方法、URL 以及协议版本
• 请求头
• 空行：表示请求头部结束
• 请求正文，get 请求没有

响应报文主要由 4 部分组成：

• 状态行：由 3 部分组成：协议版本，状态码以及状态码描述
• 响应头
• 空行
• 响应正文

HTTP常见请求方法

• GET：用于请求访问已经被 URI 识别的资源，可以通过 URL 传参给服务器。
• POST：用于传输信息给服务器，主要功能与 GET 方法类似，但一般推荐使用 POST 方式。
• PUT：传输文件，报文主体中包含文件内容，保存到对应 URI 位置。
• HEAD：获得报文首部，与 GET 方法类似，只是不返回报文主体。
• DELETE：删除文件，与 PUT 方法相反，删除对应 URI 位置的文件。
• OPTIONS：查询相应 URL 支持的 HTTP 方法

http请求流程

浏览器与服务器之间将完成下列 7 个步骤：

• 建立 TCP 连接：在HTTP工作开始之前，浏览器首先要通过网络与服务器建立连接，该连接是通过 TCP 来完成的。

• 浏览器向服务器发送请求行：一旦建立了TCP连接，浏览器就会向服务器发送请求命令。例如：GET /sample/hello.jsp HTTP/1.1。

• 浏览器发送请求头：浏览器发送其请求命令之后，还要以头信息的形式向服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

• 服务器应答：客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。

• 服务器发送应答头：正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

• 服务器向浏览器发送数据：服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以 Content-Type 应答头信息所描述的格式发送用户所请求的实际数据。

• 发送完毕：TCP 连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

HTTP返回码

1xx：指示信息--表示请求已接收，继续处理。

2xx：成功--表示请求已被成功接收、理解、接受。

3xx：重定向--要完成请求必须进行更进一步的操作。

4xx：客户端错误--请求有语法错误或请求无法实现。

5xx：服务器端错误--服务器未能实现合法的请求。

HTTP和HTTPS的区别

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。

1. https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2. http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3. http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全 .
4. HTTP 的端口号是 80，HTTPS 的端口号是 443。

SSL握手过程

1. ClientHello

   首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

2. SeverHello

   服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。

3. 客户端回应

   客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的 真实性。

4. 服务器的最后回应

   服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的 「会话秘钥」。然后，向客户端发生最后的信息：

HTTPS的加密方式

对称加密：加密和解密使用相同的密钥，如 DES 算法等。

非对称加密：使用两个密钥：公钥和私钥，用公钥加密，只有对应的私钥才能解密；而用私钥加密，只有用对应的公钥才能解密。如 RSA 算法等。

1. 混合加密

   HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

   在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。

   在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

   采用「混合加密」的方式的原因： 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但 速度慢。

2. 摘要算法

   摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改 的风险。

   服务端通过摘要算法将数据重新生成指纹，两指纹匹配则说明数据没有被篡改

3. 数字证书

   客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

   这就存在些问题，如何保证公钥不被篡改和信任度？

   所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数 字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

RSA算法

首先取两个不相等的质数p与q，并计算pq乘积n，n的二进制长度就是密钥的长度，计算n的欧拉函数值f，然后选出一个与f互质，且大小在1到f之间的数e，计算e模为f的逆元d，此时ed = 1 (mod f)

将n与e封装成公钥，n与d封装为私钥即可。

cookie 和 session的区别

cookie和session都是用来跟踪浏览器用户身份的会话方式。

cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上 ， 它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。 cookie的作用就是为了解决HTTP协议无状态的缺陷所作的努力

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。

• 存储位置不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
• 存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
• 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
• 存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。

http中浏览器一个URL的流程，这个过程中浏览器做些什么，URL包括哪三个部分？

• 浏览器向DNS服务器查找输入URL对应的IP地址。
  • 浏览器搜索自身的 DNS 缓存
  • 搜索操作系统 DNS 缓存
  • 读取本地 host 文件
  • 本机先向本地域名服务器进行递归查询
  • 本地域名服务器采用迭代查询，向一个根域名服务器查询，得到顶级域名服务器的 IP。
  • 查询顶级域名服务器，得到权限域名服务器的 IP。
  • 再查询权限域名服务器，得到域名的 IP，缓存并返回
• DNS服务器返回网站的IP地址。
• 浏览器根据IP地址与目标web服务器在80端口上建立TCP连接
• 浏览器获取请求页面的html代码。
• 浏览器在显示窗口内渲染HTML。
• 窗口关闭时，浏览器终止与服务器的连接。

域名解析

域名系统 DNS 是因特网使用的命名系统，用于把便于人们记忆的主机名转换为便于机器处理的 IP 地址。DNS 协议主要运行在 UDP 上，使用 53 号端口。

域名解析是把域名映射成 IP 地址或者把 IP 地址映射成域名的过程，域名解析有两种方式：递归查询和迭代查询：

1. DNS服务器首先会查询本地服务器资源中是否有要查询的域名记录
2. DNS会继续查询本地浏览器缓存中是否有查询记录
3. 主机向本地域名服务器查询时采用递归查询。也就是说本地域名服务器不知道被查询域名的 IP 地址，那么本地域名服务器会替主机继续查询，向其他 根域名服务器发出查询请求报文。
4. 主机域名服务器向根域名服务器的查询通常采用迭代查询。即根域名服务器收到本地域名服务器发出的迭代查询报文后，给出 IP 地址或者给出下一步查询的服务器。

本机如何得知DNS服务器地址？

通过DHCP协议， 当连接到网络后， 本机会发送DHCP广播报文向附近的DHCP服务器请求ip，DHCP收到后会将ip地址和DNS服务器地址都推送过来。

QUIC

QUIC ，即 快速UDP网络连接 ( Quick UDP Internet Connections )， 是由 Google 提出的实验性网络传输协议 ，位于 OSI 模型传输层。 QUIC 旨在解决 TCP 协议的缺陷，并最终替代 TCP 协议， 以减少数据传输，降低连接建立延迟时间，加快网页传输速度。

• 多流设计

  采用错路服用思想，一个连接承载多个流可以同时发起请求

• 低等待延迟

  将tcp与tls连接合二为一，降低延迟

• 更优的安全机制

• 前向纠错机制

  采用纠错机制，每n个包发送一个校验和，前面若丢包可以使用校验和复原

• 连接保持

实战场景题

服务端保存了大量的time_wait怎么解决？ 如果是close_wait呢？

linux分配给用户的文件句柄是有限的，time wait 和 close wait的保持会占用文件句柄，一旦达到了文件句柄上限，新的请求就无法被受理了吗，也就是too many open files 异常。

服务器保持了大量TIME_WAIT状态

修改内核参数。

**对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255，默认值是5，对应于180秒左右时间**

net.ipv4.tcp_syn_retries=2

#net.ipv4.tcp_synack_retries=2

**表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为300秒**

net.ipv4.tcp_keepalive_time=1200

net.ipv4.tcp_orphan_retries=3

**表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间**

net.ipv4.tcp_fin_timeout=30  

#表示SYN队列的长度，默认为1024，**加大队列长度为8192**，可以容纳更多等待连接的网络连接数。

net.ipv4.tcp_max_syn_backlog = 4096

#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭

net.ipv4.tcp_syncookies = 1

#**表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭**

net.ipv4.tcp_tw_reuse = 1

#**表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭**

net.ipv4.tcp_tw_recycle = 1

##**减少超时前的探测次数** 

net.ipv4.tcp_keepalive_probes=5 

##**优化网络设备接收队列** 

Close wait

接收到对方的结束请求后，服务器端没有释放连接。

就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着 。查看服务端代码是否出现问题。