知识体系总结（二）计算机网络与网络编程

---

layout: post
title: 八股总结（二）计算机网络与网络编程
description: 八股总结（二）计算机网络与网络编程
tag: 八股总结

---

计算机网络

网络模型

网络体系结构

OSI七层模型是法律上规定的国际标准，但TCP/IP体系占据了市场，是实际上的国际标准，为了方便理解，由将TCP/IP四层的结构中的网络接口层分为了物理层和数据链路层。

• 物理层的数据为比特流，数据链路层为帧，网络层为包，传输层为数据段。
• 各层常用的网络协议有哪些？
  • 数据链路层：ARP（地址解析协议）
  • 网络层：IP协议、ICMP（网际控制报文协议）、VPN、内部网关协议（如路由信息协议RIP）、外部网关协议（如边界网关协议BGP）
  • 传输层：TCP（传输控制协议）、UDP（用户数据报协议）
  • 应用层：DNS（域名解析），FTP（文件传输），DHCP（动态主机配置协议），HTTP（超文本传输协议）

网络协议栈数据报文发送与接收过程中的变化：

在浏览器输入一个网址后回车，背后都发生了什么？

1. 查看浏览器缓存，如果没有
2. 向DNS服务器发送DNS请求（采用的是UDP协议），查询本地DNS服务器。
3. 如果本地DNS查不到，就从根域名服务器，递归的查询每一级域名服务器，直到查到为止。
4. 有了DNS解析结果，我们就有了服务器的ip地址，以及默认的端口号了，http默认端口号是80，https默认端口号443。
5. 首先尝试使用http协议，调用Socket经过三次握手建立TCP连接，开始传送数据，如果正好采用http协议通信，直接返回。
6. 如果不是http协议，服务器会返回一个5开头的重定向消息，告诉我们应该使用https，于是TCP四次挥手关闭对端口80的连接。
7. TCP三次握手尝试连接443端口，采用SSL/TSL握手，沟通好双方使用的数字证书认证、加密和检验算法。
8. 确认无误后，开始通信，服务器会返回你所要访问网址的一些数据，在此过程中会将界面进行渲染，使得我们能够看到色彩斑斓的网页。

数据链路层

通俗来讲，数据链路层完成的是从目的主机所在路由器（目的MAC地址）到本地路由器（源MAC地址）的连接。

地址解析ARP（address resolution protocol）协议

ARP地址解析协议只能在单个数据链路段中使用，用于将IP地址解析为对应的MAC地址。

网络层

通俗来讲，网络层完成目的主机和本地主机之间的连接。

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

IP 地址分成两种意义：
⼀个是⽹络号，负责标识该 IP 地址是属于哪个⼦⽹的；
⼀个是主机号，负责标识同⼀⼦⽹下的不同主机。

网际控制报文协议ICMP（internet control message protocol）

为了有效转发IP数据报和提高交付成功的机会，网际层使用了网际控制报文协议ICMP，使得主机和路由器可以使用ICMP来发送差错报告报文 和 询问报文，ICMP报文被封装在IP数据报中发送。
ICMP差错报文分为以下5种：

传输层

网络层已经解决了主机与主机之间的通信，而传输层要解决的是两个主机各自进程间进行通信的问题。

TCP协议

什么是TCP协议？

TCP是面向连接的、可靠的、基于字节流的传输层通信协议。

• 面向连接：一定是一对一才能连接，不像UDP协议可以一台主机同时向多个主机发送消息。也就是说TCP只能一对一，不能像UDP那样一对多。
• 可靠的：无论网络链路中出现怎样的链路变化，TCP都可以保证一个报文一定能够到达接收端；
• 字节流：消息是无边界的，所以无论我们的消息有多大都可以进行传输，而且消息是有序的，当前一个没有收到的时候，即使它先收到了后边的字节，那么也不能扔给应用层去处理，同时对重复的报文会自动丢弃。

什么是TCP粘包/拆包？发生的原因？解决方法？

一个完整的业务可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这个就是TCP的拆包和粘包问题。

原因
1、应用程序写入数据的字节大小大于套接字发送缓冲区的大小.

2、进行MSS大小的TCP分段。( MSS=TCP报文段长度-TCP首部长度)

3、以太网的payload大于MTU进行IP分片。（ MTU指：一种通信协议的某一层上面所能通过的最大数据包大小。）

解决方案：
1、增加消息长度字段。

2、在包尾部增加回车或者空格符等特殊字符进行分割

3、将消息分为消息头和消息尾

4、使用其它复杂的协议，如RTMP协议等。

TCP和UDP的区别

• 连接：TCP是面向连接的传输层协议，传输数据前需要先建立连接，而UDP是不需要连接，即刻传输数据。
• 服务对象：TCP是一对一两点服务，UDP支持一对一、一对多和多对多
• 可靠性：TCP是可靠交付数据，数据可以无差错、不丢失、不重复、按需到达；UDP是尽最大努力交付，不保证可靠交付数据
• 拥塞控制、流量控制：TCP有拥塞控制和流量控制机制，保证数据传输的安全性，UDP则没有，即便是网络非常拥堵，也不会影响UDP的发送速率。
• 首部开销：TCP首部长，而UDP首部只有8个字节
• 传输方式：TCP是流式传输，没有边界，但是保证顺序和可靠；UDP是一个包一个包的发送，是有边界的，但是可能会丢包和乱序。

TCP和UDP的应用场景？

由于TCP是面向连接的，能够保证数据的可靠性交付，因此经常被用于FTP文件传输，HTTP、HTTPS

由于UDP是面向无连接的，它可以随时发送数据，加上UDP本身的处理既简单又高效，因此经常用于包总量较少的通信，如DNS、SNMP等，视频，音频等多媒体通信，广播通信。

为什么TCP有「首部⻓度」字段，UDP没有？

原因是 TCP 有可变⻓的「选项」字段，⽽ UDP 头部⻓度则是不会变化的，⽆需多⼀个字段去记录 UDP 的⾸部⻓度。

TCP报文结构

1. 端口号：TCP是进程与进程间的通信，因此，头部两端是16位的源端口号和16位的目的端口号

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

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

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

5. 窗口大小：用于拥塞控制

6. 校验和：差错控制

7. 紧急指针：仅当前面的 URG 控制位为 1 时才有意义。它指出本数据段中为紧急数据的字节数，占 16 位。当所有紧急数据处理完后，TCP 就会告诉应用程序恢复到正常操作。即使当前窗口大小为 0，也是可以发送紧急数据的，因为紧急数据无须缓存。

8. 选项（Option）：长度不定，但长度必须是 32bits 的整数倍。

9. 数据

TCP建立连接为什么是3次握手，而不是2次或者4次？

• 三次握手才可以阻止重复历史连接的初始化（首要原因）
• 三次握手才可以同步双方的初始序列号
• 三次握手才可以避免资源浪费

客户端连续发送多次SYN建立连接的报文，在网络拥堵情况下，一次旧的SYN报文比新的SYN报文到达了服务端，那么此时服务端就会返回一个SYN + ACK报文给客户端，客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列化过期或者超时），那么客户端就会发送RST报文给服务端，表示终止这一次连接。

如果是两次握手，就不足以判断当前连接是否为历史连接。

SYN攻击（DDOS攻击）原理及避免方法

我们都知道 TCP 连接建⽴是需要三次握⼿，假设攻击者短时间伪造不同 IP 地址的 SYN 报⽂，服务端每接收到⼀个 SYN 报⽂，就进⼊ SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报⽂，⽆法得到未知 IP 主机的 ACK 应答，久⽽久之就会占满服务端的 SYN 接收队列（未连接队列），使得服务器不能为正常⽤户服务。

TCP连接4挥手断开连接

• 客户端打算关闭连接，此时会发送⼀个 TCP ⾸部 FIN 标志位被置为 1 的报⽂，也即 FIN 报⽂，之后客户端进⼊ FIN_WAIT_1 状态。
• 服务端收到该报⽂后，就向客户端发送 ACK 应答报⽂，接着服务端进⼊ CLOSED_WAIT 状态。
• 客户端收到服务端的 ACK 应答报⽂后，之后进⼊FIN_WAIT_2 状态。
• 等待服务端处理完数据后，也向客户端发送 FIN 报⽂，之后服务端进⼊ LAST_ACK 状态。
• 客户端收到服务端的 FIN 报⽂后，回⼀个 ACK 应答报⽂，之后进⼊ TIME_WAIT 状态
• 服务器收到了 ACK 应答报⽂后，就进⼊了 CLOSED 状态，⾄此服务端已经完成连接的关闭。
• 客户端在经过 2MSL ⼀段时间后，⾃动进⼊ CLOSED 状态，⾄此客户端也完成连接的关闭。

MSL 是 Maximum Segment Lifetime，报⽂最⼤⽣存时间

服务器出现了大量的TIME_WAIT或CLOSE_WAIT可能是什么原因，该怎么办？

首先可以通过下面的命令统计当前系统中time_wait或close_wait的数量

ss- tan state time-wait | wc -l

ss 命令可以用来获取 socket 统计信息，它显示的内容和 netstat 类似。但 ss 的优势在于它能够显示更多更详细的有关 TCP 和连接状态的信息，而且比 netstat 更快。

一般而言，TIME_WAIT状态对CPU的开销影响不会太大，只是多占用了端口，使得这些端口短时间内得不到释放。

如果执意想减小这些影响，可以有以下三个方法：

• 禁用socket延迟关闭
  通常情况当close被调用时，SOCKET需要延迟关闭(lingering)，在内核buffers中的残留数据将会发送到远程地址，同时，socket会切换到TIME-WAIT状态。如果禁用此选项，则调用close之后，底层也会关闭，不会将Buffers中残留数据未发送的数据继续发送。
• 禁用net.ipv4.tcp_tw_reuse
  这个选项有什么作用呢？根据名称也能猜到，这个选项可以重用TIME_WAIT状态下的连接。默认情况下TIME_WAIT状态的时间是60s(linux中)，而如果开启了这个选项，当系统需要发起新的outgoing connection时，如果新的时间戳比之前TIME_WAIT连接的时间戳大的话（大于1s），则可直接复用原有的TIME_WAIT连接。即：TIME-WAIT状态的连接，仅仅1秒后就可以被重用了。
• 禁用net.ipv4.tcp_tw_recycle
  这个选项同样依赖时间戳选项，同样更加选项名称也能猜到，这个选项可以加快TIME_WAIT状态连接的回收时间（不开启默认是60s）。如果开启了这个选项，则TIME_WAIT的回收时间变为一个3.5个RTO（超时重传时间），当然这个时间是随网络状态动态变化的，有RTT计算而来。这个选项对所有的TIME_WAIT状态都有影响，包括incoming connections和 outgoing connections。所以开启这个选项，对客户和服务端都会产生影响。

CLOSE_WAIT是状态太多可能是由于服务端迟迟没有发送FIN，所导致的，可能的原因有两个

• 在对方关闭连接后，自身程序里没有检测（被动方）
• 主动方忘了需要关闭连接，于是整个资源就一直被程序占用着。

因此大量close_wait的出现可能是程序中，没有及时关闭进程所导致的，需要仔细检查程序中是否忘记检测关闭状态，是否检测到关闭，但自身的关闭指令被延迟或遗忘了。

TCP重传机制

TCP 针对数据包丢失的情况，会⽤重传机制解决。常见的重传机制如下：

1. 超时重传：是在发送数据时，设定⼀个定时器，当超过指定的时间后，没有收到对⽅的 ACK 确认应答报⽂，就会重发该数据，也就是我们常说的超时重传。（发送数据包丢失和对方ACK数据包丢失都会触发超时重传）

RTO（Retransmission Timeout 超时重传时间）根据RTT（Round-Trip Time ，往返时延/）确定。

2. 快速重传
   快速重传的⼯作⽅式是当收到三个相同的 ACK 报⽂时，会在定时器过期之前，重传丢失的报⽂段。
   
   快速重传机制只解决了⼀个问题，就是超时时间的问题，但是它依然⾯临着另外⼀个问题。就是重传的时候，是重
   传之前的⼀个，还是重传所有的问题。
   ⽐如对于上⾯的例⼦，是重传 Seq2 呢？还是重传 Seq2、Seq3、Seq4、Seq5 呢？因为发送端并不清楚这连续的
   三个 Ack 2 是谁传回来的。

3. SACK （ Selective Acknowledgment 选择性确认）重传
   这种⽅式需要在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄，它可以将缓存的地图发送给发送⽅，这样发送⽅就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
   如下图，发送⽅收到了三次同样的 ACK 确认报⽂，于是就会触发快速重发机制，通过 SACK 信息发现只有200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进⾏重复。如果要⽀持 SACK ，必须双⽅都要⽀持。在 Linux 下，可以通过 net.ipv4.tcp_sack 参数打开这个功能（Linux2.4 后默认打开）。

4. Duplicate SACK ⼜称 D-SACK ，其主要使⽤了 SACK 来告诉「发送⽅」有哪些数据被重复接收了。
例子1：

• 「接收⽅」发给「发送⽅」的两个 ACK 确认应答都丢失了，所以发送⽅超时后，᯿传第⼀个数据包（3000 ~
  3499）
• 于是「接收⽅」发现数据是重复收到的，于是回了⼀个 SACK = 3000~3500，告诉「发送⽅」 3000~3500 的数据早已被接收了，因为 ACK 都到了 4000 了，已经意味着 4000 之前的所有数据都已收到，所以这个 SACK就代表着 D-SACK 。
• 这样「发送⽅」就知道了，数据没有丢，是「接收⽅」的 ACK 确认报⽂丢了。

例子2：

• 数据包（1000~1499） 被⽹络延迟了，导致「发送⽅」没有收到 Ack 1500 的确认报⽂。
• ⽽后⾯报⽂到达的三个相同的 ACK 确认报⽂，就触发了快速重传机制，但是在重传后，被延迟的数据包（1000~1499）⼜到了「接收⽅」；
• 所以「接收⽅」回了⼀个 SACK=1000~1500，因为 ACK 已经到了 3000，所以这个 SACK 是 D-SACK，表示收到了重复的包。这样发送⽅就知道快速重传触发的原因不是发出去的包丢了，也不是因为回应的 ACK 包丢了，⽽是因为⽹络延迟了。

可见使用D-SACK的好处是：

• 可以让发送方知道，是发出的包丢了，还是接收方回应的ACK包丢了；
• 可以知道是不是发送包的数据包被网络延迟了

在 Linux 下可以通过 net.ipv4.tcp_dsack 参数开启/关闭这个功能（Linux 2.4 后默认打开）。

TCP滑动窗口

#1 是已发送并收到 ACK确认的数据：1~31 字节
#2 是已发送但未收到 ACK确认的数据：32~45 字节
#3 是未发送但总⼤⼩在接收⽅处理范围内（接收⽅还有空间）：46~51字节
#4 是未发送但总⼤⼩超过接收⽅处理范围（接收⽅没有空间）：52字节以后

TCP 滑动窗⼝⽅案使⽤三个指针来跟踪在四个传输类别中的每⼀个类别中的字节。其中两个指针是绝对指针（指特
定的序列号），⼀个是相对指针（需要做偏移）。

接收部分如上图所示，其中三个接收部分，使⽤两个指针进⾏划分:
RCV.WND ：表示接收窗⼝的⼤⼩，它会通告给发送⽅。
RCV.NXT ：是⼀个指针，它指向期望从发送⽅发送来的下⼀个数据字节的序列号，也就是 #3 的第⼀个字节。
指向 #4 的第⼀个字节是个相对指针，它需要 RCV.NXT 指针加上 RCV.WND ⼤⼩的偏移ᰁ，就可以指向 #4 的
第⼀个字节了。

流量控制

发送⽅不能⽆脑的发数据给接收⽅，要考虑接收⽅处理能⼒。
如果⼀直⽆脑的发数据给对⽅，但对⽅处理不过来，那么就会导致触发重传机制，从⽽导致⽹络流重的⽆端的浪费。

为了解决这种现象发⽣，TCP 提供⼀种机制可以让「发送⽅」根据「接收⽅」的实际接收能⼒控制发送的数据量，
这就是所谓的流量控制。

1、假如发送方报文丢失，那么接收方回传的ack会一直不包含丢失字段，则发送方会在重传等待时间结束后对丢失报文段进行重传。接收方利用接受窗口大小这个参考，控制发送方的发送速率。

2、假如接收方有了新的可缓存空间，并将消息发送给发送方的途中，报文丢失，那么发送方一直以为接收方没有空间接收，而接收方也并不知道自己的报文丢失。这样就陷入死锁状态。为了打破死锁，发送方每发送一次报文都会启动一个持续计时器，当持续计时器超时的时候，发送零窗口探测报文。询问是否依旧是没有缓存空间。零窗口探测报文对于接收方没有空间要求，且也有超时重传机制。

拥塞控制

前⾯的流量控制是避免「发送⽅」的数据填满「接收⽅」的缓存，但是并不知道⽹络的中发⽣了什么。

而拥塞控制是当⽹络发送拥塞时，TCP 会⾃我牺牲，降低
发送的数据量。控制的⽬的就是避免「发送⽅」的数据填满整个⽹络。

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

• 慢开始：从1开始倍数增长。

• 拥塞避免：如果当拥塞窗⼝ cwnd 「超过」慢启动⻔限 ssthresh就进入拥塞避免算法。一般ssthresh的大小是65535。进入拥塞避免算法后，每次线性增加1。如果网络发送拥塞，有丢包现象发生，就会触发重传机制，将ssthresh 设为 cwnd/2，cwnd窗口值设置为1，并执行慢开始算法。
  

• 快重传：发送方一旦收到3个连续的重复确认，立即重传相应报文段。TCP认为在还能收到3个连续重复确认的情况下，说明大部分没丢，只是丢了一小部分。于是将cwnd拥塞窗口设置为原来的一半，将ssthresh设置为cwnd，然后进入快速恢复算法。

• 快恢复：拥塞窗口 cwnd = ssthresh + 3（3的意思是确认有3个数据包收到了），重传丢失的数据包，如果再收到重复的ACK，那么cwnd增加1.

UDP协议

应用层

HTTP

HTTP 是⼀个在计算机世界⾥专⻔在「两点」之间「传输」⽂字、图⽚、⾳频、视频等「超⽂本」数据的「约定和
规范」

session，cookie，token的应用与区别

由于http是无状态的会话，所以我们需要一个东西来记录区分不同用户的信息，主要有下边三种方式

• session ：在服务端记录，每一个会话会产生一个session。当某用户打开某个web应用时，便与web服务器产生一次session。服务器使用session将用户的信息临时保存在服务器上，用户离开网站后，session会自动销毁，这样服务器就会根据每个人的sessionid不同，从而区别开不同用户的请求，返回给用户不同的请求结果。

  • 缺点： 在目前服务器都使用分布式部署的情况下，万一上一个请求和下一个请求，响应的是不同的服务器，那么后边没用存储session的机器就会任务该请求没用登录。如果使用session复制，将会增加很多开销，不是理想方案。

• cookie
  cookie是服务端保存在客户端的临时的少量的数据，cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时，会把该cookie发送给服务器。cookie是存在客户端的，所以浏览器加入了一些限制，以确保cookie不会被恶意使用，同时不会占用太多磁盘空间，所以每个域的cookie的数量是有限的。

  • 缺点：cookie这种方式很容易被恶意攻击者入侵，黑客会伪造session来登录访问。这个时候就需要一种加密的方法，来验证这个cookie的id是否由我自己的服务器之前生成，而非伪造或者篡改的。

• token
  token是服务端生成的一串字符，当作客户端进行请求的一个令牌，当第一次登录后，服务器为客户端生成一个token（令牌），以后客户端只需要带上这个token来请求，就会被视为登录状态。

• 区别：

  • session存在服务器端，cookie存在客户端，token是服务器分配给客户端，客户带token访问视为登录。

HTTP常见字段有哪些？

host字段：客户端发送请求时，用来指定服务器的域名，有了host字段就可以将请求发往同一台服务器上的不同网站
content-length 字段：服务器在返回数据时会有content-length字段，表示本次回应的数据长度
connection字段：connection字段最常用于客户端要求服务器使用TCP持久连接，以便其他请求复用。
HTTP/1.1 版本的默认连接都是持久连接，但为了兼容⽼版本的 HTTP，需要指定 Connection ⾸部字段的值为Keep-Alive

Connection: keep-alive

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

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

客户端请求的时候，可以使⽤ Accept 字段声明⾃⼰可以接受哪些数据格式。

Content-Encoding 字段
Content-Encoding 字段说明数据的压缩⽅法。表示服务器返回的数据使⽤了什么压缩格式
客户端在请求时，⽤ Accept-Encoding 字段说明⾃⼰可以接受哪些压缩⽅法。

HTTP状态码

1xx 类状态码属于提示信息，是协议处理中的⼀种中间状态，实际⽤到的⽐较少

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

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

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

• 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改⽤新的 URL 再次访问。
• 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要⽤另⼀个 URL 来访问。
• 301 和 302 都会在响应头⾥使⽤字段 Location ，指明后续要跳转的 URL，浏览器会⾃动重定向新的 URL。
• 「304 Not Modified」不具有跳转的含义，表示资源未修改，᯿定向已存在的缓冲⽂件，也称缓存重定向，⽤于缓存控制

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

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

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

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

GET和POST的区别？

Get （获取）⽅法的含义是请求从服务器获取资源，这个资源可以是静态的⽂本、⻚⾯、图⽚视频等。

POST（投递） ⽅法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报⽂的 body ⾥。

HTTP和HTTPS的区别？

1. HTTP是超文本传输协议，信息是明文传输，存在安全风险问题，HTTPS则解决了HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
2. HTTP连接建立简单，TCP三次握手之后便可以进行HTTP的报文传输，而HTTPS在TCP三次握手之后，还需要进行SSL/TSL握手，才可以进入加密报文传输。
3. HTTP的端口号是80，HTTPS的端口号是443
4. HTTPS协议需要向CA(证书权威机构)申请数字证书，来保证服务器身份是可信的。

HTTPS解决了HTTP哪些问题，是怎么解决的？

HTTP由于是明文传输，安全上存在窃听、篡改和冒充的风险。
HTTPS在HTTP与TCP层之间加入了SSL/TSL协议，通过对信息的混合加密，防止窃听；采用校验机制，使用摘要算法，为数据生成独一无二的指纹，用于校验数据的完整性，防止数据篡改；将服务器公钥放入到数字证书中，解决身份冒充的风险。

对称加密和非对称加密的区别

• 对称加密: 加密和解密的秘钥使用的是同一个，常用的对称加密算法如（DES）
• 非对称加密：非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。使用公钥加密的，只能通过私钥解密。

对称加密的缺点： 在数据传送前，发送方和接收方必须商定好秘钥，然后 使双方都能保存好秘钥。其次如果一方的秘钥被泄露，那么加密信息也就不安全了。另外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。

非对称加密算法：公钥相当于寄信口的锁，将公钥发给所有的消息发送方，消息发送方持有公钥才可向接收方发送消息，私钥相当于收信门的锁，自己保留使用，用于查看接收的信息。

数字证书是什么？

非对称加密，存在一个公钥传输的问题，这个时候就需要数字证书了，基于非对称加密公私钥分离的特性，我们就可以对公钥进行单独操作，用于数字证书，也叫数字认证（digital certificate），即相当于现实生活中的签名，用于证实身份。数字证书就是公钥的载体。

SLL/TLS协议的流程

以使用RSA算法实现秘钥交换的TLS协议版本为例：

1. 客户端向服务端发送Client Hello数据包，包含客户端随机数C，客户端支持的TLS版本号、密码套件列表。
2. 服务端从客户端发来的密码套件列表，选择RSA加密，回复客户端，服务端的随机数S、确认的TLS版本号、使用RSA加密、并将自己的证书发给客户端。
3. 证书校验方法已经事先置入客户端的浏览器或者操作系统，因此客户端拿到服务端发送的证书会首先校验证书的有效性，如果有效，则取出证书中的公钥。并使用该公钥加密一个新的随机数pre-master，再发送给服务端。
4. 服务端收到后，使用自己的私钥解密得到这个新的随机数pre-master，至此，服务端和客户端都拥有了客户端随机数C、服务端随机数S和pre-master，通过这三个随机数，客户端和服务端各自生成会话秘钥。这个秘钥是一种对称秘钥。
5. 接下来的同学双方就使用这个生成的会话秘钥进行通信。

HTTP/1.1、HTTP/2、HTTP/3演变

HTTP/1.1 相⽐ HTTP/1.0 性能上的改进：
使⽤ TCP ⻓连接的⽅式改善了 HTTP/1.0 短连接造成的性能开销。
⽀持管道（pipeline）⽹络传输，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以
减少整体的响应时间

但 HTTP/1.1 还是有性能瓶颈：
请求 / 响应头部（Header）未经压缩就发送，⾸部信息越多延迟越⼤。只能压缩 Body 的部分；
发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多；
服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端⼀直请求不到数据，也就是队头阻塞；
没有请求优先级控制；
请求只能从客户端开始，服务器只能被动响应。

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
其他改进：

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 请求剩下的部分。
5. 服务器推送
   HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式，服务不再是被动地响应，也可以主动向客户端发
   送消息。
   举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会⽤到的 JS、CSS ⽂件等静态资源主动发给客户端，减
   少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

HTTP/2 主要的问题在于，多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求
的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的重传机制，这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等
待这个丢了的包被重传回来

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

UDP 发⽣是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的⼀个丢包全部᯿传问
题。
⼤家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC 有⾃⼰的⼀套机制可以保证传输的可靠性的。当某个流发⽣丢包时，只会阻塞这个流，其他流不会受到
影响。
TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack 。
HTTPS 要建⽴⼀个连接，要花费 6 次交互，先是建⽴三次握⼿，然后是 TLS/1.3 的三次握⼿。QUIC 直接把
以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。

Web Socket协议

webSoket 出现是因为普通的http请求，只是客户端发送请求，然后服务器接收，想要获取服务器端的消息只能通过Ajax请求，但h5之后出现的webSoket，打破了这一僵局~~~实现了客户端和服务器端全双工通信。

• 特点：建立连接之后一直保持连接状态。
• 连接建立过程：
  1、客户端发送GET 请求， upgrade
  2、服务器给客户端 switching protocol
  3、就进行了webSocket的通信了

域名解析协议（DNS，Domain Name System）

1. 客户端⾸先会发出⼀个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端
   的 TCP/IP 设置中填写的 DNS 服务器地址）。
2. 本地域名服务器收到客户端的请求后，如果缓存⾥的表格能找到 www.server.com，则它直接返回 IP 地址。如
   果没有，本地 DNS 会去问它的根域名服务器：“⽼⼤， 能告诉我 www.server.com 的 IP 地址吗？” 根域名服
   务器是最⾼层次的，它不直接⽤于域名解析，但能指明⼀条道路。
3. 根 DNS 收到来⾃本地 DNS 的请求后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域管
   理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。”
4. 本地 DNS 收到顶级域名服务器的地址后，发起请求问“⽼⼆， 你能告诉我 www.server.com 的 IP 地址吗？”
5. 顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
6. 本地 DNS 于是转向问权威 DNS 服务器：“⽼三，www.server.com对应的IP是啥呀？” server.com 的权威 DNS
   服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
7. 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
8. 本地 DNS 再将 IP 地址返回客户端，客户端和⽬标建⽴连接。

为什么域名解析用UDP协议？

因为UDP快啊！UDP的DNS协议只要一个请求、一个应答就好了。
而使用基于TCP的DNS协议要三次握手、发送数据以及应答、四次挥手，但是UDP协议传输内容不能超过512字节。
不过客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。

动态主机配置协议（DHCP，Dynamic Host Configuration Protocol）

Linux网络编程

BIO / NIO / AIO

同步与异步

• 同步 ：两个同步任务相互依赖，并且一个任务必须以依赖于另一任务的某种方式执行。 比如在A->B事件模型中，你需要先完成 A 才能执行B。 再换句话说，同步调用中被调用者未处理完请求之前，调用不返回，调用者会一直等待结果的返回。
• 异步： 两个异步的任务完全独立的，一方的执行不需要等待另外一方的执行。再换句话说，异步调用中一调用就返回结果不需要等待结果返回，当结果返回的时候通过回调函数或者其他方式拿着结果再做相关处理。
  

阻塞与非阻塞

阻塞： 阻塞就是发起一个请求，调用者一直等待请求结果返回，也就是当前线程会被挂起，无法从事其他任务，只有当条件就绪才能继续。
非阻塞： 非阻塞就是发起一个请求，调用者不用一直等着结果返回，可以先去干其他事情。

如何区分 “同步/异步 ”和 “阻塞/非阻塞” 呢？

同步和异步关注的是任务完成消息通知的机制，而阻塞和非阻塞关注的是等待任务完成时请求者的状态。

• 同步就是普通水壶烧开水，要没事儿自己过来来看开没开；
• 异步就是响水壶烧开水，水开了水壶响了通知你。
• 阻塞是烧开水的过程中，你不能干其他事情（即你被阻塞住了）；
• 非阻塞是烧开水的过程里可以干其他事情。比如出去和老相好聊聊天，去客厅看看电视

BIO

BIO(Blocking I/O)：同步阻塞I / O 模式

服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销。

NIO

BIO(Non-blocking)：同步非阻塞I / O 模式

NIO有几个知识点需要掌握，Channel(通道)，Buffer(缓冲区), Selector（多路复用选择器）。

• Channel既可以用来进行读操作，又可以用来进行写操作。NIO中常用的Channel有FileChannel
  、SocketChannel、ServerSocketChannel、DatagramChannel。
• Buffer缓冲区用来发送和接受数据。
• Selector 一般称为选择器或者多路复用器 。它是Java NIO核心组件中的一个，用于检查一个或多个NIO Channel（通道）的状态是否处于可读、可写。在javaNIO中使用Selector往往是将Channel注册到Selector中。

NIO通过一个Selector，负责监听各种IO事件的发生，然后交给后端的线程去处理。NIO相比与BIO而言，非阻塞体现在轮询处理上。BIO后端线程需要阻塞等待客户端写数据，如果客户端不写数据就一直处于阻塞状态。而NIO通过Selector进行轮询已注册的客户端，当有事件发生时才会交给后端去处理，后端线程不需要等待。

AIO

Asynchronous I / O 异步非阻塞IO

在Java 7中引入了NIO的改进版NIO 2,它是异步非阻塞的IO模型。异步IO是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。

TCP的socket编程

1. 服务端和客户端初始化 socket ，得到⽂件描述符；
2. 服务端调⽤ bind ，将绑定在 IP 地址和端⼝;
3. 服务端调⽤ listen ，进⾏监听；
4. 服务端调⽤ accept ，等待客户端连接；
5. 客户端调⽤ connect ，向服务器端的地址和端⼝发起连接请求；
6. 服务端 accept 返回⽤于传输的 socket 的⽂件描述符；
7. 客户端调⽤ write 写⼊数据；服务端调⽤ read 读取数据；
8. 客户端断开连接时，会调⽤ close ，那么服务端 read 读取数据的时候，就会读取到了 EOF ，待处理完数据后，服务端调⽤ close ，表示连接关闭。

需要注意的是：监听的 socket 和真正⽤来传送数据的 socket，是「两个」 socket，⼀个叫作监听 socket，⼀个叫作已完 成连接 socket。

成功连接建⽴之后，双⽅开始通过 read 和 write 函数来读写数据，就像往⼀个⽂件流⾥⾯写东⻄⼀样。

Linux内核中会维护两个队列：

• 半连接队列（SYN 队列）：接收到⼀个 SYN 建⽴连接请求，处于 SYN_RCVD 状态；
• 全连接队列（Accpet 队列）：已完成 TCP 三次握⼿过程，处于 ESTABLISHED 状态；