网络协议是计算机在通信过程中要遵循的一些约定好的规则。
网络分层的原因：
- 易于实现和维护，因为各层之间是独立的，层与层之间不会受到影响。
- 有利于标准化的制定
计算机网络体系可以大致分为一下三种，七层模型、五层模型和TCP/IP四层模型，一般面试能流畅回答出五层模型就可以了，表示层和会话层被问到的不多。
- 应用层，负责向用户提供一组应用程序，常见的应用层协议有DNS，HTTP协议，FTP文件传输协议、SMTP等。而且应用层是工作在操作系统中的用户态，传输层及以下则工作在内核态。
- 表示层，表示层的主要作用是数据的表示、安全、压缩。可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
- 会话层，会话层的主要作用是建立通信链接，保持会话过程通信链接的畅通，同步两个节点之间的对话，决定通信是否被中断以及通信中断时决定从何处重新发送。
- 运输层，传输层的主要作用是负责向两台主机进程之间的通信提供数据传输服务（端到端的通信）。传输层的协议主要有TCP、UDP。
- 网络层，网络层的主要作用是选择合适的网间路由和交换结点，确保数据及时送达(负责网络包的封装、分片、路由、转发)。常见的协议有IP、ICMP。
- 数据链路层，数据链路层的作用是在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路，通过差错控制提供数据帧（Frame）在信道上无差错的传输，并进行各电路上的动作系列（数据在相邻网络结点间的传输）。 常见的协议有SDLC、HDLC、PPP、以太网等。
- 物理层，物理层的主要作用是实现相邻计算机结点之间比特流的透明传输，并尽量屏蔽掉具体传输介质和物理设备的差异（在线路上传输比特流）。
-
URI(Uniform Resource Identifier)：中文全称为统一资源标志符，主要作用是唯一标识一个资源。
-
URL(Uniform Resource Location)：中文全称为统一资源定位符，主要作用是提供资源的路径。
有个经典的比喻是URI像是身份证，可以唯一标识一个人，而URL更像一个住址，可以通过URL找到这个人。
域名系统
DNS是集群式的工作方式还是 单点式的，为什么？
答案是集群式的，很容易想到的一个方案就是只用一个DNS服务器，包含了所有域名和IP地址的映射。尽管这种设计方式看起来很简单，但是缺点显而易见，如果这个唯一的DNS服务器出了故障，那么就全完了，因特网就几乎崩了。为了避免这种情况出现，DNS系统采用的是分布式的层次数据数据库模式，还有缓存的机制也能解决这种问题。
DNS的工作流程
主机向本地域名服务器的查询一般是采用递归查询，而本地域名服务器向根域名的查询一般是采用迭代查询。
递归查询主机向本地域名发送查询请求报文，而本地域名服务器不知道该域名对应的IP地址时，本地域名会继续向根域名发送查询请求报文，不是通知主机自己向根域名发送查询请求报文。
迭代查询是，本地域名服务器向根域名发出查询请求报文后，根域名不会继续向顶级域名服务器发送查询请求报文，而是通知本地域名服务器向顶级域名发送查询请求报文。
简单来说，递归查询就是，小明问了小红一个问题，小红不知道，但小红是个热心肠，小红就去问小王了，小王把答案告诉小红后，小红又去把答案告诉了小明。迭代查询就是，小明问了小红一个问题，小红也不知道，然后小红让小明去问小王，小明又去问小王了，小王把答案告诉了小明。
1.在浏览器中输入www.mianshi.online域名，操作系统会先检查自己本地的hosts文件是否有这个域名的映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2.如果hosts文件中没有，则查询本地DNS解析器缓存，如果有，则完成地址解析。
3.如果本地DNS解析器缓存中没有，则去查找本地DNS服务器，如果查到，完成解析。
4.如果没有，则本地服务器会向根域名服务器发起查询请求。根域名服务器会告诉本地域名服务器去查询哪个顶级域名服务器。
5.本地域名服务器向顶级域名服务器发起查询请求，顶级域名服务器会告诉本地域名服务器去查找哪个权限域名服务器。 本地域名服务器向权限域名服务器发起查询请求，权限域名服务器告诉本地域名服务器www.mianshi.online所对应的IP地址。
6.本地域名服务器告诉主机www.mianshi.online所对应的IP地址。
ARP协议属于网络层的协议(地址解析协议)，主要作用是实现从IP地址转换为MAC地址。在每个主机或者路由器中都建有一个ARP缓存表，表中有IP地址及IP地址对应的MAC地址。先来看一下什么时IP地址和MAC地址。
- IP地址：IP地址是指互联网协议地址，IP地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。
- MAC地址：MAC地址又称物理地址，由网络设备制造商生产时写在硬件内部，不可更改，并且每个以太网设备的MAC地址都是唯一的。
ARP的工作流程(面试时问ARP协议主要说这个就可以了)：
- 在局域网内，主机A要向主机B发送IP数据报时，首先会在主机A的ARP缓存表中查找是否有IP地址及其对应的MAC地址，如果有，则将MAC地址写入到MAC帧的首部，并通过局域网将该MAC帧发送到MAC地址所在的主机B。
- 如果主机A的ARP缓存表中没有主机B的IP地址及所对应的MAC地址，主机A会在局域网内广播发送一个ARP请求分组。局域网内的所有主机都会收到这个ARP请求分组。
- 主机B在看到主机A发送的ARP请求分组中有自己的IP地址，会向主机A以单播的方式发送一个带有自己MAC地址的响应分组。
- 主机A收到主机B的ARP响应分组后，会在ARP缓存表中写入主机B的IP地址及其IP地址对应的MAC地址。
- 如果主机A和主机B不在同一个局域网内，即使知道主机B的MAC地址也是不能直接通信的，必须通过路由器转发到主机B的局域网才可以通过主机B的MAC地址找到主机B。并且主机A和主机B已经可以通信的情况下，主机A的ARP缓存表中寸的并不是主机B的IP地址及主机B的MAC地址，而是主机B的IP地址及该通信链路上的下一跳路由器的MAC地址。这就是上图中的源IP地址和目的IP地址一直不变，而MAC地址却随着链路的不同而改变。
简单来说，标识网络中的一台计算机，比较常用的就是IP地址和MAC地址，但计算机的IP地址可由用户自行更改，管理起来相对困难，而MAC地址不可更改，所以一般会把IP地址和MAC地址组合起来使用。具体是如何组合使用的在上面的ARP协议中已经讲的很清楚了。
那只用MAC地址不用IP地址可不可以呢？
其实也是不行的，因为在最早就是MAC地址先出现的，并且当时并不用IP地址，只用MAC地址，后来随着网络中的设备越来越多，整个路由过程越来越复杂，便出现了子网的概念。对于目的地址在其他子网的数据包，路由只需要将数据包送到那个子网即可，这个过程就是上面说的ARP协议。
那为什么要用IP地址呢？
是因为IP地址是和地域相关的，对于同一个子网上的设备，IP地址的前缀都是一样的，这样路由器通过IP地 址的前缀就知道设备在在哪个子网上了，而只用MAC地址的话，路由器则需要记住每个MAC地址在哪个子网，这需要路由器有极大的存储空间，是无法实现的。
IP地址可以比作为地址，MAC地址为收件人，在一次通信过程中，两者是缺一不可的。
ping是ICMP(网际控制报文协议)中的一个重要应用，ICMP是网络层的协议。ping的作用是测试两个主机的连通性。 ping的工作过程：
1.向目的主机发送多个ICMP请求报文
2.根据目的主机返回的回送报文的时间和成功响应的次数估算出数据包往返时间及丢包率。
| 所属网络模型的层级 | 功能 | |
|---|---|---|
| 路由器 | 网络层 | 识别IP地址并根据IP地址转发数据包，维护数据表并基于数据表进行最佳路径选择 |
| 交换机 | 数据链路层 | 识别MAC地址并根据MAC地址转发数据帧 |
腾讯一面
| 是否面向连接 | 可靠性 | 传输形式 | 传输效率 | 消耗资源 | 应用场景 | 首部字节 | |
|---|---|---|---|---|---|---|---|
| TCP | 面向连接 | 可靠 | 字节流 | 慢 | 多 | 文件/邮件传输 | 20-60 |
| UDP | 无连接 | 不可靠 | 快 | 少 | 视屏/语音传输 | 8 |
❤有时候面试还会问到TCP的首部都包含什么
TCP首部：前20个字节是固定的，后面又4n个字节是根据需要而增加的选项，最小长度为20个字节
UDP的首部只有8个字节，源端口号、目的端口号、长度和校验和各两个字节。
主要有校验和、序列号、超时重传、流量控制及拥塞避免等几种方法。
腾讯一面
- 校验和：在发送方和接收端分别计算数据的校验和，如果两者不一致，则说明数据在传输的过程中出现了差错，TCP将丢弃和不确认次报文
- 序列号：TCP会对每一个发送的字节进行编号，接收方接到数据后，会对发送方发送确认应答(ACK报文)，并且这个ACK报文中带有相应的确认编号，告诉发送方，下一次发送的数据从编号多少开始发。如果发送方发送相同的数据，接收端也可以通过序列号判断出，直接将数据丢弃。
-
超时重传：在上面说了序列号的作用，但如果发送方在发送数据后一段时间内（可以设置重传计时器规定这段时间）没有收到确认序号ACK，那么发送方就会重新发送数据。这里发送方没有收到ACK可以分两种情况，如果是发送方发送的数据包丢失了，接收方收到发送方重新发送的数据包后会马上给发送方发送ACK；如果是接收方之前接收到了发送方发送的数据包，而返回给发送方的ACK丢失了，这种情况，发送方重传后，接收方会直接丢弃发送方冲重传的数据包，然后再次发送ACK响应报文。如果数据被重发之后还是没有收到接收方的确认应答，则进行再次发送。此时，等待确认应答的时间将会以2倍、4倍的指数函数延长，直到最后关闭连接。
-
流量控制：如果发送端发送的数据太快，接收端来不及接收就会出现丢包问题。为了解决这个问题，TCP协议利用了滑动窗口进行了流量控制。在TCP首部有一个16位字段大小的窗口，窗口的大小就是接收端接收数据缓冲区的剩余大小。接收端会在收到数据包后发送ACK报文时，将自己的窗口大小填入ACK中，发送方会根据ACK报文中的窗口大小进而控制发送速度。如果窗口大小为零，发送方会停止发送数据。
-
拥塞控制：如果网络出现拥塞，则会产生丢包等问题，这时发送方会将丢失的数据包继续重传，网络拥塞会更加严重，所以在网络出现拥塞时应注意控制发送方的发送数据，降低整个网络的拥塞程度。拥塞控制主要有四部分组成：慢开始、拥塞避免、快重传、快恢复，如下图(图片来源于网络)。
这里的发送方会维护一个拥塞窗口的状态变量，它和流量控制的滑动窗口是不一样的，滑动窗口是根据接收方数据缓冲区大小确定的，而拥塞窗口是根据网络的拥塞情况动态确定的，一般来说发送方真实的发送窗口为滑动窗口和拥塞窗口中的最小值。
-
慢开始：为了避免一开始发送大量的数据而产生网络阻塞，会先初始化cwnd为1，当收到ACK后到下一个传输轮次，cwnd为2，以此类推成指数形式增长。
-
拥塞避免：因为cwnd的数量在慢开始是指数增长的，为了防止cwnd数量过大而导致网络阻塞，会设置一个慢开始的门限值ssthresh，当cwnd>=ssthresh时，进入到拥塞避免阶段，cwnd每个传输轮次加1。但网络出现超时，会将门限值ssthresh变为出现超时cwnd数值的一半，cwnd重新设置为1，如上图，在第12轮出现超时后，cwnd变为1，ssthresh变为12。
-
快重传：在网络中如果出现超时或者阻塞，则按慢开始和拥塞避免算法进行调整。但如果只是丢失某一个报文段，如下图(图片来源于网络)，则使用快重传算法。
-
但是根据快重传算法，要求在这种情况下，需要快速向发送端发送M2的确认报文，在发送方收到三个M2的确认报文后，无需等待重传计时器所设置的时间，可直接进行M3的重传，这就是快重传。
- 快恢复：从上上图圈4可以看到，当发送收到三个重复的ACK，会进行快重传和快恢复。快恢复是指将ssthresh设置为发生快重传时的cwnd数量的一半，而cwnd不是设置为1而是设置为为门限值ssthresh，并开始拥塞避免阶段。
-
必考题
在介绍三次握手和四次挥手之前，先介绍一下TCP头部的一些常用字段。
序号：seq，占32位，用来标识从发送端到接收端发送的字节流。
确认号：ack，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。
标志位：
SYN：发起一个新连接。
FIN：释放一个连接。
ACK：确认序号有效。
三次握手
三次握手的本质就是确定发送端和接收端具备收发信息的能力，在能流畅描述三次握手的流程及其中的字段含义作用的同时还需要记住每次握手时接收端和发送端的状态。这个比较容易忽略。
开始时客户端和服务端的状态都是CLOSE。
- 第一次握手：客户端向服务端发起建立连接请求，客户端会随机生成一个起始序列号x，客户端向服务端发送的字段中包含标志位SYN=1，序列号seq=x。客户端进入SYN-SENT状态
- 第二次握手：服务端在收到客户端发来的报文后，会随机生成一个服务端的起始序列号y，然后给客户端回复一段报文，其中包括标志位SYN=1，ACK=1，序列号seq=y，确认号ack=x+1。服务端进入SYN-RCVD状态（其中SYN=1表示要和客户端建立一个连接，ACK=1表示确认序号有效）
- 第三次握手：客户端收到服务端发来的报文后，会再向服务端发送报文，其中包含标志位ACK=1，序列号seq=x+1，确认号ack=y+1。客户端进入**ESTABLE-LISHED ** （əˈstabliSHt）阶段，服务端接收到报文后也会进入ESTABLE-LISHED阶段，开始数据传输。
四次挥手
假设客户端首先发起的断开连接请求
- 第一次挥手：客户端向服务端发送的数据完成后，向服务端发起释放连接报文，报文包含标志位FIN=1，序列号seq=u。此时客户端只能接收数据，不能向服务端发送数据。
- 第二次挥手：服务端收到客户端的释放连接报文后，向客户端发送确认报文，包含标志位ACK=1，序列号seq=v，确认号ack=u+1。此时客户端到服务端的连接已经释放掉，客户端不能向服务端发送数据。但服务端到客户端的单向连接还能正常传输数据。
- 第三次挥手：服务端发送完数据后向客户端发出连接释放报文，报文包含标志位FIN=1，标志位ACK=1，序列号seq=w，确认号ack=u+1。
- 第四次挥手：客户端收到服务端发送的释放连接请求，向服务端发送确认报文，包含标志位ACK=1，序列号seq=u+1，确认号ack=w+1。
不可以，主要从以下方面考虑（假设客户端是首先发起连接请求）：
-
避免重复历史连接（主要原因）
三次握手的首要原因是为了防止旧的重复连接初始化造成混乱
两次握手无法避免历史连接：
如果服务端接收到了一个早已失效的来自客户端的连接请求报文，会向客户端发送确认报文同意并立即建立TCP连接。但因为客户端并不需要向服务端发送数据，所以此次TCP连接没有意义。
-
同步双方的初始序列号
序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的
SYN报文的时候，需要服务端回一个ACK应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。 -
避免资源浪费
如果只有「两次握手」，当客户端发生的
SYN报文在网络中阻塞，客户端没有接收到ACK报文，就会重新发送SYN，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的 ACK 报文，所以服务端每收到一个 SYN 就只能先主动建立一个连接如果客户端发送的
SYN报文在网络中阻塞了，重复发送多次SYN报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
至于四次握手，三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。
因为需要确保通信双方都能通知对方释放连接
假设客户端发送完数据向服务端发送释放连接请求，当客户端并不知道，服务端是否已经发送完数据，所以此次断开的是客户端到服务端的单向连接，服务端返回给客户端确认报文后，服务端还能继续单向给客户端发送数据。当服务端发送完数据后还需要向客户端发送释放连接请求，客户端返回确认报文，TCP连接彻底关闭。所以断开TCP连接需要客户端和服务端分别通知对方并分别收到确认报文，一共需要四次。
默认客户端首先发起断开连接请求
从图中可以看出
- CLOSE_WAIT是被动关闭形成的，当客户端发送FIN报文，服务端返回ACK报文后进入CLOSE_WAIT。
- TIME_WAIT是主动关闭形成的（等待2MSL），当第四次挥手完成后，客户端进入TIME_WAIT状态。
客户端主动关闭连接时，会发送最后一个ack后，然后会进入TIME_WAIT状态，再停留2个MSL时间，进入CLOSED状态
MSL就是maximum segment lifetime(最大分节生命期），这是一个IP数据包能在互联网上生存的最长时间，超过这个时间IP数据包将在网络中消失 。MSL在RFC 1122上建议是2分钟，而源自berkeley的TCP实现传统上使用30秒。
MSL的意思是报文的最长寿命，可以从两方面考虑：
- 防止新连接收到旧链接的TCP报文： 防止历史连接中的数据，被后面相同四元组的连接错误的接收，客户端发送第四次挥手中的报文后，再经过2MSL，可使本次TCP连接中的所有报文全部消失，不会出现在下一个TCP连接中。 2*MSL 的时间足以保证两个方向上的数据都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定是新连接上产生的。
- 防止连接关闭时四次挥手中的最后一次ACK丢失 ：考虑丢包问题，如果第四挥手发送的报文在传输过程中丢失了，那么服务端没收到确认ack报文就会重发第三次挥手的报文。如果客户端发送完第四次挥手的确认报文后直接关闭，而这次报文又恰好丢失，则会造成服务端无法正常关闭。
如果TCP连接已经建立，在通信过程中，客户端突然故障，那么服务端不会一直等下去，过一段时间就关闭连接了。具体原理是TCP有一个保活机制，主要用在服务器端，用于检测已建立TCP链接的客户端的状态，防止因客户端崩溃或者客户端网络不可达，而服务器端一直保持该TCP链接，占用服务器端的大量资源(因为Linux系统中可以创建的总TCP链接数是有限制的)。
保活机制原理：
设置TCP保活机制的保活时间keepIdle，即在TCP链接超过该时间没有任何数据交互时，发送保活探测报文；设置保活探测报文的发送时间间隔keepInterval；设置保活探测报文的总发送次数keepCount。如果在keepCount次的保活探测报文均没有收到客户端的回应，则服务器端即关闭与客户端的TCP链接。
具体细节请看这篇博客TCP通信过程中异常情况整理TCP通信过程中异常情况整理_自由不死的博客-CSDN博客_tcp通讯故障。
腾讯
| HTTP | HTTPS | |
|---|---|---|
| 端口 | 80 | 443 |
| 安全性 | 无加密，安全性较差 | 有加密机制，安全性较高 |
| 资源消耗 | 较少 | 由于加密处理，资源消耗更多 |
| 是否需要证书 | 不需要 | |
| 协议 | 运行在TCP协议之上 | 运行在SSL协议之上，SSL运行在TCP协议上 |
- HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
- HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
- 两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
- HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
- 对称加密对称加密指加密和解密使用同一密钥，优点是运算速度快，缺点是如何安全将密钥传输给另一方。常见的对称加密算法有DES、AES等等。
- 非对称加密非对称加密指的是加密和解密使用不同的密钥，一把公开的公钥，一把私有的私钥。公钥加密的信息只有私钥才能解密，私钥加密的信息只有公钥才能解密。优点解决了对称加密中存在的问题。缺点是运算速度较慢。常见的非对称加密算法有RSA、DSA、ECC等等。非对称加密的工作流程：A生成一对非堆成密钥，将公钥向所有人公开，B拿到A的公钥后使用A的公钥对信息加密后发送给A，经过加密的信息只有A手中的私钥能解密。这样B可以通过这种方式将自己的公钥加密后发送给A，两方建立起通信，可以通过对方的公钥加密要发送的信息，接收方用自己的私钥解密信息。
上面已经介绍了对称加密和非对称加密的优缺点，HTTPS是将两者结合起来，使用的对称加密和非对称加密的混合加密算法。具体做法就是使用非对称加密来传输对称密钥来保证安全性，使用对称加密来保证通信的效率。
HTTPS的加密过程：
- 客户端向服务端发起第一次握手请求，告诉服务端客户端所支持的SSL的指定版本(协议版本号)、支持的加密算法以及一个客户端生成的随机数
- 服务端确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数
- 客户端确认数字证书有效，然后生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，发给服务端
- 服务端收到后利用自己的私钥解密信息，获得客户端发来的随机数。
- 客户端和服务端根据约定的加密方法，使用前三个随机数，生成“对话秘钥”（session key），用来加密接下来的整个对话过程。
上述流程存在的一个问题是客户端哪里来的数字认证机构的公钥，其实，在很多浏览器开发时，会内置常用数字证书认证机构的公钥。 流程图如下：
数字证书的工作流程:
这也是一个面试经常问的题目，背下来就行了
| 状态码 | 类别 |
|---|---|
| 1xx | 信息性状态码 |
| 2xx | 成功状态码 |
| 3xx | 重定向状态码 |
| 4xx | 客户端错误状态码 |
| 5xx | 服务端错误状态码 |
常见的HTTP状态码
1XX
- 100 Continue：表示正常，客户端可以继续发送请求
- 101 Switching Protocols：切换协议，服务器根据客户端的请求切换协议。
2XX
- 200 OK：请求成功，服务器返回的响应头都会有 body 数据
- 204 No Content：无内容，服务器成功处理，但未返回内容，与 200 OK 基本相同，但响应头没有 body 数据。
- 206 Partial Content：是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。
3XX
-
301 Moved Permanently：表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
-
302 Found：表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。
4XX
- 400 Bad Request：客户端请求的报文有错误，但只是个笼统的错误。
- 401 Unauthorized：表示发送的请求需要有认证信息。
- 403 Forbidden：服务器禁止访问资源，并不是客户端的请求出错
- 404 Not Found：服务器无法根据客户端的请求找到资源。
5XX
- 500 Internal Server Error：服务器内部错误，与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
- 501 Not Implemented：表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思
- 502 Bad Gateway ：通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
- 503 Service Unavailable：表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。
| 方法 | 作用 |
|---|---|
| GET | 获取资源 |
| POST | 传输数据，向服务器提交数据，对服务器数据进行更新 |
| PUT | 上传文件，向服务器添加数据 |
| DELETE | 删除文件 |
| HEAD | 和GET方法类似，但只返回报文实体主体部分 |
| PATCH | 对资源进行部分修改 |
| OPTIONS | 查询指定的URL支持的方法 |
| CONNECT | 要求用隧道协议连接代理 |
| TRACE | 服务器会将通行路径返回给客户端 |
- 作用： GET用于获取服务器上的资源，POST用于传输实体主体（修改服务器的资源）
- 参数位置： GET的参数放在URL中，POST的参数存储在body中，并且GET方法提交的请求的URL中的数据最多是2048字节，POST请求没有大小限制。
- 安全性 ：GET方法因为参数放在URL中，安全性相对于POST较差一些
- 幂等性： GET方法是具有幂等性的，而POST方法不具有幂等性。这里幂等性指客户端连续发出多次请求，收到的结果都是一样的.
HTTP 1.0和HTTP 1.1的区别
- 长连接HTTP 1.1支持长连接和请求的流水线（管道网络传输）操作。长连接是指不在需要每次请求都重新建立一次连接，HTTP 1.0默认使用短连接，每次请求都要重新建立一次TCP连接，资源消耗较大。请求的流水线操作是指客户端在收到HTTP的响应报文之前可以先发送新的请求报文，不支持请求的流水线操作需要等到收到HTTP的响应报文后才能继续发送新的请求报文。
- 缓存处理在HTTP 1.0中主要使用header中的If-Modified-Since,Expires作为缓存判断的标准，HTTP 1.1引入了Entity tag，If-Unmodified-Since, If-Match等更多可供选择的缓存头来控制缓存策略。
- 错误状态码在HTTP 1.1新增了24个错误状态响应码
- HOST域在HTTP 1.0 中认为每台服务器都会绑定唯一的IP地址，所以，请求中的URL并没有传递主机名。但后来一台服务器上可能存在多个虚拟机，它们共享一个IP地址，所以HTTP 1.1中请求消息和响应消息都应该支持Host域。
- 带宽优化及网络连接的使用在HTTP 1.0中会存在浪费带宽的现象，主要是因为不支持断点续传功能，客户端只是需要某个对象的一部分，服务端却将整个对象都传了过来。在HTTP 1.1中请求头引入了range头域，它支持只请求资源的某个部分，返回的状态码为206。
HTTP 2.0的新特性
- 二进制格式：HTTP 1.x的解析是基于文本，HTTP 2.0的解析采用二进制，实现方便，健壮性更好。
- 多路复用：每一个request对应一个id，一个连接上可以有多个request，每个连接的request可以随机混在一起，这样接收方可以根据request的id将request归属到各自不同的服务端请求里。
- header压缩：在HTTP 1.x中，header携带大量信息，并且每次都需要重新发送，HTTP 2.0采用编码的方式减小了header的大小，同时通信双方各自缓存一份header fields表，避免了header的重复传输。
- 服务端推送：客户端在请求一个资源时，会把相关资源一起发给客户端，这样客户端就不需要再次发起请求。
HTTP协议是无状态的，即服务器无法判断用户身份。Session和Cookie可以用来进行身份辨认。
-
Cookie是保存在客户端一个小数据块，其中包含了用户信息。当客户端向服务端发起请求，服务端会像客户端浏览器发送一个Cookie，客户端会把Cookie存起来，当下次客户端再次请求服务端时，会携带上这个Cookie，服务端会通过这个Cookie来确定身份。
-
Session是通过Cookie实现的，和Cookie不同的是，Session是存在服务端的。当客户端浏览器第一次访问服务器时，服务器会为浏览器创建一个sessionid，将sessionid放到Cookie中，存在客户端浏览器。比如浏览器访问的是购物网站，将一本《图解HTTP》放到了购物车，当浏览器再次访问服务器时，服务器会取出Cookie中的sessionid，并根据sessionid获取会话中的存储的信息，确认浏览器的身份是上次将《图解HTTP》放入到购物车那个用户。
-
Token客户端在浏览器第一次访问服务端时，服务端生成的一串加密的字符串作为Token发给客户端浏览器，下次浏览器在访问服务端时携带token即可无需验证用户名和密码，省下来大量的资源开销。
token可以通过将token加入请求参数或者请求头来抵抗csrf（跨站请求伪造攻击，盗用登录信息发起请求）,cookie+session不行
因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击
cookie、session与token的真正区别下面为了方便记忆，做了一个表格进行对比。
| 存放位置 | 占用空间 | 安全性 | 应用场景 | |
|---|---|---|---|---|
| cookie | 客户端浏览器 | 小 | 较低 | 一般存放配置信息 |
| session | 服务端 | 多 | 较高 | 存放较为重要的信息 |
可以，Session的作用是在服务端来保持状态，通过sessionid来进行确认身份，但sessionid一般是通过Cookie来进行传递的。如果Cooike被禁用了，可以通过在URL中传递sessionid。
面试超高频的一道题，一般能说清楚流程就可以。
- 对输入到浏览器的url进行DNS解析，将域名转换为IP地址（此时可以讲一讲DNS的解析过程，本机hosts文件->本地DNS服务器缓存->本地DNS服务器->根域名服务器发起迭代查询）。
- 通过ARP协议获取目的服务器的MAC地址，找到目的服务器（缓存->广播）
- 与目的服务器通过三次握手建立TCP连接
- 向目的服务器发送HTTP请求
- 服务器处理请求并返回HTTP报文
- 浏览器解析并渲染页面
所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持。
短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接，一般银行都使用短连接。
其实长连接是相对于通常的短连接而说的，也就是长时间保持客户端与服务端的连接状态。
使用场景：
数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源
可以的。
在数据链路层中，通过 MAC 地址来寻找局域网中的主机。在网际层中，通过 IP 地址来寻找网络中互连的主机或路由器。在传输层中，需要通过端口进行寻址，来识别同一计算机中同时通信的不同应用程序。
所以，传输层的「端口号」的作用，是为了区分同一个主机上不同应用程序的数据包。
传输层有两个传输协议分别是 TCP 和 UDP，在内核中是两个完全独立的软件模块。
当主机收到数据包后，可以在 IP 包头的「协议号」字段知道该数据包是 TCP/UDP，所以可以根据这个信息确定送给哪个模块（TCP/UDP）处理，送给 TCP/UDP 模块的报文根据「端口号」确定送给哪个应用程序处理。
因此，TCP/UDP 各自的端口号也相互独立，如 TCP 有一个 80 号端口，UDP 也可以有一个 80 号端口，二者并不冲突。
小红书一面
当TCP连接中出现太多TIME_WAIT状态的情况时，可能会导致服务器资源耗尽或性能下降。TIME_WAIT状态是TCP连接正常关闭后的一种状态，用于确保在网络中的所有数据都被完全传输和处理。然而，**如果连接频繁关闭，就会产生大量的TIME_WAIT状态，这可能会占用服务器资源并影响性能。**以下是一些处理太多TIME_WAIT状态的方法：
- 调整系统参数：
- 调整TIME_WAIT状态的超时时间：您可以通过修改系统内核参数来缩短TIME_WAIT状态的超时时间，从而更快地释放这些资源。例如，可以调整
net.ipv4.tcp_fin_timeout参数。 - 增加可用端口范围：通过扩大可用端口范围，可以减少TIME_WAIT状态的竞争，这可以通过修改
net.ipv4.ip_local_port_range参数来实现。
- 调整TIME_WAIT状态的超时时间：您可以通过修改系统内核参数来缩短TIME_WAIT状态的超时时间，从而更快地释放这些资源。例如，可以调整
- 使用连接重用：
- 考虑在应用程序中实现连接重用，而不是频繁地关闭和重新创建连接。这可以减少TIME_WAIT状态的生成，提高性能（比如tcp长连接）。
- 负载均衡：
- 使用负载均衡器将请求分发到多个服务器实例，以分散TIME_WAIT状态的影响。这可以帮助分散TIME_WAIT状态的负载，从而减轻单个服务器的压力。
- 使用连接池：
- 对于数据库连接等资源密集型应用，使用连接池来管理连接，以减少连接的频繁创建和关闭。
- 考虑TCP快速回收：
- 某些Linux内核版本支持TCP快速回收，它允许更快地回收TIME_WAIT状态的连接资源。您可以查看是否有此选项，并根据需要启用它。
请注意，在进行任何系统参数的更改时，务必小心，以免影响系统的稳定性和安全性。建议在测试环境中进行这些更改，并监控系统性能，以确保没有不良影响。不同的操作系统和内核版本可能有不同的参数名称和配置方法，因此您需要查阅相关文档以获得详细信息。