计算机网络

基础

五层协议

1. 应用层 ：1 直接为用户的应用进程提供数据传输服务；2 应用层协议有HTTP、DNS等；3 数据单位为报文；
2. 传输层 ：1 为主机中的多个进程提供通用的数据传输服务；2 由于一个主机可同时运行多个进程，因此传输层有复用和分用的功能：复用，就是多个应用层进程可同时使用下面传输层的服务；分用，就是把收到的信息分别交付给上面应用层中相应的进程；3 传输层包括两种协议：传输控制协议 TCP，提供面向连接、可靠的数据传输服务，数据单位为报文段；用户数据报协议 UDP，提供无连接、尽最大努力交付的数据传输服务，数据单位为用户数据报；
3. 网络层 ：1 为分组交换网上的不同主机提供数据传输服务；2 网络层把传输层传递下来的报文段或者用户数据报封装成分组；3 选中合适的路由，使源主机的分组能够通过网络中的路由器找到目标主机；4 网络层协议有IP（网际协议）、ARP（地址解析协议）、RARP（逆地址解析协议）等；5 数据单位为分组；
4. 数据链路层 ：1 网络层针对的是主机之间的数据传输服务，而主机之间可以有很多链路，链路层协议就是为同一链路的主机提供数据传输服务；2 数据链路层把网络层传下来的分组封装成帧；3 数据链路层地址为MAC地址；4 数据单位为帧；
5. 物理层 ：1 主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等；2 数据单位为比特；

OSI七层协议

相比于五层模型，OSI七层协议多出了表示层和会话层：

• 表示层 ：数据编码、数据压缩、加密以及数据描述，这使得应用程序不必关心在各台主机中数据内部格式不同的问题；
• 会话层 ：建立及管理会话，典型应用RPC；

五层协议没有表示层和会话层，而是将这些功能留给应用程序开发者处理。

TCP/IP四层协议

1. 只有四层，相当于五层协议中数据链路层和物理层合并为网络接口层；
2. TCP/IP 体系结构不严格遵循 OSI 分层概念，应用层可能会直接使用 IP 层或者网络接口层；

3. TCP/IP 协议族是一种沙漏形状，中间小两头大，IP 协议在其中占据举足轻重的地位；
   

IP（网络层）和MAC（数据链路层）之间的区别和联系

1. IP的作用是实现主机之间通信，MAC的作用是实现直连的两个设备之间通信；
2. 举例：1 小明去一个很远的地方旅游，要转好多次火车，于是制定了一个行程表，行程表标识了行车路线，小明购买了火车票，每一张火车票只在限定区间有效；2 行程表就相当于网络层，行程开始好比源IP，行程终点好比目的IP；每个火车区间就相当于数据链路层，区间出发点好比源MAC地址，区间目标点好比目的MAC地址；3 源IP地址和目标IP地址在传输过程中是不会变化的，而源 MAC 地址和目标MAC地址⼀直在变化；

网络中两台主机通信完整过程*

1 主机A和主机B在同一个二层网络中，直接走二层交换

1. 1 主机A查看自己的ARP缓存，检查是否有主机B的IP到MAC的映射，如果有映射，构造报文，目的IP为主机B的IP，源IP为主机A的IP，目的MAC为主机B的MAC，源MAC为主机A的MAC，将报文发送给交换机C，交换机C进行MAC地址表学习，将主机A的MAC和报文入端口号记录下来；2 然后交换机C查看自己的MAC转发表，检查是否有主机B的MAC到端口的映射，如果有映射，获取对应的端口，将报文从此端口转发出去，报文到达主机B；3 如果交换机C没有主机B的MAC转发表映射，则采用洪泛的形式广播报文，主机B收到报文后向主机A回复，交换机C进行MAC表学习，将主机B的MAC和报文入端口号记录下来；

2. 1 如果主机A的ARP缓存中没有主机B的IP到MAC的映射，主机A需要先发送ARP请求，以获取主机B的MAC； 2 A将报文发往交换机C，交换机C采用洪泛的形式广播报文，主机B收到广播报文后，在自己的ARP缓存表中写入主机A的IP到MAC的映射，将自己的MAC封装到ARP回复报文中，单播给主机A，主机A获取到主机B的MAC后，在自己的ARP缓存表中写入主机B的IP到MAC的映射，构造报文发送给主机B，过程同上；

3. 主机B向主机A回复报文的过程类似；

2 主机A和主机B不在同一个网络中，走三层路由

1. 主机A查看自己的ARP缓存表，检查是否有路由器E的IP到MAC的映射，如果有映射，获取路由器E的MAC，构造报文，目的IP为主机B的IP，源IP为主机A的IP，目的MAC为路由器E的MAC，源MAC为主机A的MAC，将报文通过交换机C发往路由器E，过程同上。 如果主机A没有路由器E的IP到MAC的映射，需要发送ARP请求，获取路由器E的MAC，过程同上；2. 路由器E收到主机A的报文后，剥离报文的MAC帧头，查询路由表，发现目标主机B所在的网络是直连的，查看自己的ARP缓存表，如果有主机B的IP到MAC的映射，获取主机B的MAC，封装报文MAC帧头，目的MAC为主机B的MAC，源MAC为路由器E的MAC，将报文通过交换机D发往主机B，如果路由器E没有主机B的IP到MAC的映射关系，需要发送ARP请求，获取主机B的MAC，过程同上；
2. 主机B向主机A回复报文的过程类似；

路由器是如何转发分组的

1. 提取IP分组首部中的目的IP地址D，得出其所在的网络N；
2. 判断目的IP地址所在的网络N是否与本路由器直接相连。如果是，直接交付给N，如果不是执行3；
3. 检查路由表中是否有目的IP地址的特定主机路由（对特定的目的主机指明的一个路由），如果有，按特定主机路由转发，如果没有，执行4；
4. 检查路由表中是否有到达网络N的路由，如果有，按指明的路由转发，如果没有，执行5；
5. 检查路由表中是否有默认路由，如果有按默认路由转发，如果没有，执行6；
6. 报告转发分组出错；

TCP

三次握手

1. 第 1 次握手：客户端发送 SYN 包（seq=x）到服务端，此时客户端进入SYN-SENT状态，等待服务端确认；
2. 第 2 次握手：服务器收到客户端的 SYN 包，向客户端发送确认包 ACK（ack=x+1)，同时自己发送一个 SYN 包（seq=y），即 ACK+SYN 包，此时服务端进入 SYN-RCVD状态；
3. 第 3 次握手：客户端收到服务端的 ACK+SYN 包，向服务端发送确认包 ACK（ack=y+1），此包发送并接收完毕，双方进入ESTABLISHED状态。完成了 3 次握手；

SYN:同步序列编号

三次握手的原因

原因 1

1. 为了初始化序列号；
2. 通信双方需要通知对方建立连接以后的序列号的初始值（即上面的 x 和 y），作为以后数据传输的序号，保证应用层接收到的数据不会因为网络传输问题而乱序；
3. 进行第 3 次握手，就是告知服务端，客户端已收到服务端发送的序列号的初始值了；

原因 2

1. A 向 B 发出连接请求，请求在某个节点滞留一段时间；
2. A 发送超时，认为报文丢失，重传。这一次 B 马上收到，然后与 A 建立连接。数据传输完毕后，断开连接；
3. 此时，滞留的请求到达了 B，B 又认为 A 发来请求；
4. “两次握手”：B 认为传输连接又建立，并一直等待 A 传输数据，而此时 A 并无连接请求，因此不予理睬，这造成了 B 资源的浪费；
5. “三次握手”：B 向 A 发送确认报文，由于是一个失效请求，A 不予理睬，建立连接失败；

四次挥手

1. 第 1 次挥手：客户端发送FIN连接释放报文段（FIN=1，seq=u)，并停止发送数据，客户端进入 FIN-WAIT-1状态；
2. 第 2 次挥手：服务端收到 FIN 后，发送ACK(ack=u+1) 给客户端 ，服务端进入CLOSE_WAIT状态，客户端收到后进入FIN-WAIT-2状态；
3. 第 3 次挥手：服务端发送FIN连接释放报文段（FIN=1，seq=w)，并停止发送数据，服务端进入LAST-ACK状态；
4. 第 4 次挥手：客户端收到 FIN 后，发送ACK(ack=w+1) 给服务端，客户端进入TIME-WAIT 状态，等待2MSL，接着客户端进入CLOSED状态，服务端收到后也进入CLOSED状态，完成 4 次挥手；

为什么需要TIME-WAIT状态

1. TIME-WAIT=2MSL，MSL即报文最大生存时间，主动发起关闭连接的一方，才会有TIME-WAIT状态；
2. 原因1：防止旧的数据包被收到。如果没有TIME-WAIT或者TIME-WAIT时间过短，如果有一个服务端在关闭连接之前发送的报文被网络延迟了，这时有相同端口的TCP连接被复用后，被延迟的报文抵达了客户端，那么客户端很有可能正常接收这过期的报文，就会造成数据错乱等严重问题。而经过2MSL 这个时间，足以让旧的数据包在网络中自然消失，再出现的数据包一定都是新建立连接所产生的；

3. 原因2：等待足够的时间以确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。如果客户端四次挥手的最后一个ACK报文在网络中丢失了，如果没有TIME-WAIT或者TIME-WAIT时间过短，客户端进入CLOSED状态，那么服务端会一直处在LAST-ACK状态，客户端将无法建立新的连接。而有了TIME-WAIT，如果服务端没有收到最后一个ACK报文，则会重发FIN关闭连接报文并等待新的ACK报文；

4. 因此，客户端在TIME-WAIT状态等待2MSL后，就可以保证双方的连接正常关闭；

四次挥手的原因

1. 因为 TCP 连接是全双工通信，发送方和接收方都需要 FIN 报文和 ACK 报文，其中一方关闭是被动的；
2. 客户端发送 FIN 连接释放报文之后，服务器收到了这个报文，进入CLOSE-WAIT 状态，这个状态是为了让服务端发送尚未发送完毕的数据，发送完毕之后，服务端会发送 FIN 连接释放报文；

TCP和UDP

1. TCP：1 传输控制协议，是面向连接的通信协议；2 在数据传输时，发送端和接收端要建立逻辑连接，每次连接的创建都要经过三次握手，每次连接的释放都要经过四次挥手，提供了可靠无差错的数据传输；3 下载文件浏览网页等;
2. UDP：1 用户数据报协议，是无连接的通信协议；2 在数据传输时，发送端和接收端不建立逻辑连接，发送端不会确认接收端是否存在就会发送数据，接收端在收到数据后也不会向发送端反馈是否收到，不能保证数据完整性； 3 在传输重要数据时不建议，但通信效率高可用于音视频会议，丢失一两个数据包没大影响;

TCP协议如何保证可靠传输

1. 检验和：在发送端和接收端分别计算数据的校验和，如果两者不一致，就说明数据在传输过程中出现了差错，TCP将丢弃和不确认此报文段；
   

2. 序列号：TCP会对每一个发送的字节进行编号，接收方接到数据后，会对发送方发送确认应答(ACK报文)，并且这个ACK报文中带有相应的确认编号，告诉发送方，下一次发送的数据从编号多少开始发。如果发送方发送相同的数据，接收方也可以通过序列号判断出，直接将数据丢弃；

3. 超时重传：如果发送方在发送数据后一段时间内没有收到确认序号ACK，那么发送方就会重新发送数据（发送方没收到ACK分两种情况：1发送方发送的数据包丢失了，接收方收到发送方重新发送的数据包后马上给发送方发送ACK；2接收方之前接收到了发送方发送的数据包，但返回给发送方的ACK丢失了，这种情况，发送方重传后，接收方会直接丢弃发送方重传的数据包，然后再次发送ACK响应报文）。如果数据被重发后还是没收到接收方的确认应答，则再次重发，此时等待确认应答的时间将以2倍、4倍的指数函数延长，直到最后关闭连接；
4. 流量控制：如果发送方发送数据过快，接收方来不及接收就会出现丢包问题。为了解决这个问题，TCP协议使用滑动窗口来进行流量控制：1 在TCP首部有一个16位字段大小的窗口，接收方在收到数据包后发送ACK报文时，将自己的窗口大小填入报文段的窗口字段，发送方据此设置自己的窗口大小；2 如果窗口大小为0，发送方会停止发送数据；
5. 拥塞控制：如果网络出现拥塞，就会产生丢包等问题，这时发送方会将丢失的数据包继续重传，网络拥塞会更严重。因此在网络出现拥塞时要注意控制发送方的发送数据的速度，降低整个网络的拥塞程度。拥塞控制由4部分组成：慢开始、拥塞避免、快重传、快恢复；

ARQ协议

0. **自动重传请求（Automatic Repeat-reQuest，ARQ）**是传输层和数据链路层的错误纠正协议之⼀。它通过使⽤确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后⼀段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ；
1. 停止等待ARQ协议：1 每发完⼀个分组就停止发送，等待对方确认（回复ACK）。如果过了⼀段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下⼀个分组；在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；2 优点：简单 3 缺点：信道利用率低，等待时间长；
2. 连续ARQ协议：1 连续 ARQ 协议可提高信道利用率。发送方维持⼀个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方⼀般采用累计确认，对按序到达的最后⼀个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了；2 优点： 信道利用率高，容易实现；3 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传⼀次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的N 个消息；

TCP 滑动窗口

1. TCP使用滑动窗口做流量控制和乱序重排；窗口是缓存的一部分，用来暂时存放字节流；
2. 发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小;
3. 发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收；如果发送窗口左部的字节已发送并收到确认，就向右滑动，直到左部第一个字节不是已发送并收到确认的状态；如果接收窗口左部字节已发送确认并交付主机，就向右滑动，直到左部第一个字节不是已发送确认并交付主机的状态;
4. 接收窗口只会对窗口内最后一个按序到达的字节进行确认；例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认；发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收；

TCP 拥塞控制

0. 如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度；

TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。

为了便于讨论，做如下假设：

 - 接收方有足够大的接收缓存，因此不会发生流量控制；
 - 虽然 TCP 的窗口基于字节，但是这里设窗口的大小单位为报文段；

1 慢开始与拥塞避免

• 发送的最初执行慢开始，令 拥塞窗口cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 …
• 慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。因此设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。
• 如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。

2 快重传与快恢复

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认，发送方只要一连收到3个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计数器时间到期。

• 在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认，在收到一个失序的报文段后就立即发出重复确认，此时收到 M4，发送对 M2 的确认；收到M5，再次发送对 M2 的确认；收到M6，再次发送对 M2 的确认；
• 在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3；
• 在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免；
• 慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh；

HTTP

HTTP简介

1. 超文本传输协议：请求-响应协议，运行在TCP之上，是在客户端和服务器之间传输文字、图片、音频、视频等超文本数据的约定和规范；
2. 超文本：超越了普通文本的文本，文字、图片、音频、视频、超链接等的混合体；
3. 协议：协（两个以上参与者），议（行为约定或规范）；

HTTP常用请求方法

1. GET：从服务器请求数据；
2. POST：向服务器提交要被处理的数据（例如提交表单或上传文件）；
3. PUT：向服务器传送数据取代指定的文档内容；
4. DELETE：请求服务器删除指定页面；

GET和POST的区别

1. GET从服务器请求数据；POST向服务器提交数据（例如提交表单或上传文件）；
2. GET把请求的数据放在URL上，以?分隔URL和传输数据，参数之间以“&”连接，因此有安全隐患；而POST把数据放在HTTP的request body里，更安全；
3. GET能提交的数据量很小，通常1024字节左右，而POST通常不受限制；
4. GET产生一个TCP数据包，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；POST产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200（返回数据）；
5. GET幂等，POST非幂等（幂等性：多次执行相同的操作，结果都是相同的。由于get是只读操作，因此是安全且幂等的；post是提交数据的操作，会修改服务器上的资源，因此是不安全且不幂等的；）；

PUT和POST的区别

1. 幂等性：多次执行相同的操作，结果都是相同的；
2. put幂等，post不幂等：put将A修改为B，它第一次请求时值变成了B，再进行多次此请求，最终的结果还是B，所以幂等；post一次请求添加一份新资源，二次请求则添加了两份新资源，多次请求会产生不同结果，因此不幂等；
3. put应用场景：向指定URL更新资源，比如用户模块修改用户密码，每次提交得到的结果都是同一个新更新的密码；
4. post应用场景：向指定URL创建资源，比如用户模块用户注册，每次提交都创建一个用户账号；

HTTP为什么不用GET向服务器上传数据

（1 数据量小1024字节 2 数据在URL上安全隐患）

1. 采用get向服务器上传数据时，一般将数据添加到URL后面，二者用“?”连接，参数之间以“&”连接。由于对URL的长度存在限制，因此get能上传的数据量非常小，通常在1024字节左右；而post传递数据是通过HTTP请求的附件进行，传送的数据量要大得多，一般默认为不受限制;
2. 由于get方法上传的数据是添加在URL中的，因此上传的数据被暴露，存在安全隐患，而post方法向服务器提交的内容在URL中没有明文显示，对用户不可见，安全性更好;

HTTP长连接、短连接

（1 HTTP1.0短连接HTTP1.1长连接；2 短连接：客户端服务器每进行一次HTTP操作就建立一次TCP连接；3 长连接：一网页打开后传输HTTP数据的TCP连接不会关闭，客户端再次访问服务器继续使用这一条连接，非永久连接有限定时间，流水线方式和非流水线方式，流水线方式客户端收到HTTP响应报文之前就能接着发新请求报文，非流水线方式客户端收到前⼀个响应后才能发下⼀个请求）

1. 在HTTP/1.0中默认使用短连接。即客户端和服务器每进行⼀次HTTP操作，就建立⼀次连接，任务结束就中断连接。当浏览器访问的某个HTML或其他类型的Web页面中包含有其他的Web资源（如JS文件、CSS文件、图片等）时，每遇到这样⼀个Web资源，浏览器就会重新建立⼀个HTTP会话；
2. 从HTTP/1.1起，默认使用长连接，使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive。在使用长连接的情况下，当⼀个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这⼀条已经建立的连接。Keep-Alive不会永久保持连接，它有⼀个保持时间，可以在不同的服务器软件中设定这个时间。实现长连接需要客户端和服务端都支持长连接；HTTP/1.1的长连接有非流水线方式和流水线方式 。流水线方式是客户端在收到HTTP的响应报文之前就能接着发送新的请求报文，而非流水线方式是客户端在收到前⼀个响应后才能发送下⼀个请求；

为什么HTTP是无状态的？

（1 HTTP1.0短连接，每次请求响应一次TCP连接，每次TCP连接没有关联，所以无状态；2 HTTP1.1支持长连接，但每个请求独立，且长连接有时间限制）

1. 因为HTTP1.0是短连接，即每次“请求-响应”都是一次TCP连接。比如用户一次请求就是一次TCP连接，服务器响应结束后断开连接。而每次TCP连接是没有关联的，因此HTTP是无状态的；
2. HTTP 1.1后支持了keep-alive，即长连接，那么每次HTTP请求还是无状态吗？是的。HTTP每个请求都是独立的，Keep-Alive 没能改变这个结果。虽然HTTP 1.1为了效率，支持了keep-alive，但是这个keep-alive是有时间限制的，超过这个时间就会断开；

HTTP是不保存状态的协议,如何保存用户状态

（1 HTTP无状态，服务器不知道两次请求是否同一个用户，使用Cookie和Session保存状态；2 Session在服务端记录用户状态，在Cookie中附加SessionID发送至客户端，客户端再请求带上Cookie，识别用户，状态保持；3 Cookie被禁用？重写URL将SessionID附加在URL路径后面）

1. HTTP 是⼀种不保存状态即无状态协议，即每一次请求之间是没有联系的，都是独立的，因此服务器不知道请求两次之间是否是同一个用户。使用Cookie和Session的HTTP可以被认为是有状态的；
2. Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当用户要添加商品到购物车的时候，由于是一次新的连接且HTTP是无状态的，因此系统不知道是哪个用户操作的，而服务端通过给特定的用户创建特定的Session 之后就可以标识这个用户并且跟踪这个用户了;
3. Session 存放在服务端，通过在Cookie 中附加⼀个Session ID发至客户端并由客户端之后再请求时带上Cookie被识别的方式，来实现用户状态的保持；
4. 在服务端保存 Session 的方法很多，最常用的就是内存数据库(比如redis)；
5. Cookie 被禁用怎么办：利用 URL 重写把 Session ID 直接附加在URL路径的后面；

HTTP 1.0和HTTP 1.1的主要区别是什么

（1 长连接 2 错误状态响应码：HTTP1.1新增响应码如409请求资源与资源当前状态冲突410服务器某资源被永久性删除 3 缓存处理：HTTP1.0使用Expires、Last-Modified、If-Modified-Since作为缓存控制策略，HTTP1.1引入Etag和If-None-Match（文件内容唯一对比标记）等更多可供选择的缓存控制策略 4 带宽优化及网络连接的使用：HTTP1.0存在带宽浪费HTTP1.1优化，客户端只需要对象一部分，HTTP1.0将整个对象送过来，HTTP1.1允许只送对象某部分，状态码206）

1. 长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立⼀次连接。而HTTP 是基于TCP/IP协议的，每⼀次建立或者断开连接都需要经过三次握手四次挥手，开销比较大。从HTTP 1.1起，默认使用长连接，默认开启Connection： keep-alive。 HTTP/1.1的长连接有流水线方式和非流水线方式 。流水线方式是客户端在收到HTTP的响应报文之前就能接着发送新的请求报文，而非流水线方式是客户端在收到前⼀个响应后才能发送下⼀个请求；
2. 错误状态响应码 :在HTTP1.1中新增了错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发⽣冲突；410（Gone）表示服务器上的某个资源被永久性删除；
3. 缓存处理 :在HTTP1.0中主要使用header中的Expires、Last-Modified、If-Modified-Since来作为缓存控制策略；HTTP1.1则引入了Etag和If-None-Match（文件内容唯一对比标记）等更多可供选择的缓存控制策略；
4. 带宽优化及网络连接的使用：HTTP1.0中，存在⼀些浪费带宽的现象，例如客户端只需要某个对象的⼀部分，而服务器却将整个对象送过来了；HTTP1.1则在请求头中引入了range，它允许只请求资源的某个部分，返回的状态码是206；

HTTP2.0的新特性

（1 二进制分帧：报文分割成更小二进制帧并行发送和接收提升传输效率；2 多路复用：一TCP连接上同时多个请求和响应提升并发性能；3 首部压缩：对HTTP报文头部压缩减少数据量）

1. 二进制分帧：HTTP2.0将报文分割成更小的二进制帧，通过并行发送和接收这些帧，提高了数据的传输效率；
2. 多路复用：HTTP2.0允许在同一个TCP连接上同时发送多个请求和响应，避免了HTTP1.x中的队头阻塞问题，提高了并发性能；
3. 首部压缩：HTTP2.0使用了HPACK算法对HTTP报文头部进行压缩，减小了数据的传输量，提高了性能；

HTTP1.0和HTTP1.1中的缓存区别

（0 HTTP1.1引入Etag和If-None-Match；1 提升网页加载速度减少网络流量；2 一网页被访问，其内容被缓存到客户端，下次访问客户端先检查缓存，没过期直接用缓存不用重新下载 3 缓存控制策略：Expires资源过期时间、Last-Modified资源最新修改时间、if-Modified-Since资源最新修改时间、Etag资源标识、if-None-Match资源标识；3 三种：3.1 Expires：第一次请求返回资源A+过期时间Expires，后续请求浏览器对比当前时间是否大于Expires，不大于使用本地缓存，大于请求服务器 3.2 Expires+Last-Modified与if-Modified-Since：1. 第一次请求，返回资源A+Expires过期时间+Last-Modified资源最新修改时间，后续请求，Expires未过期，使用本地缓存；Expires过期，请求服务器时带上if-Modified-Since(即上次请求服务器返回的Last-Modified)，服务器将if-Modified-Since与Last-Modified做对比。如果相等，返回状态码304，表示资源没有修改，继续使用本地缓存；如果不相等，服务器返回最新资源A+过期时间Expires+Last-Modified； 3.3 Expires+Last-Modified与if-Modified-Since+Etag与If-None-Match：Last-Modified标注的最后修改只能精确到秒级，如果某些资源在1秒钟以内，被修改多次的话，它将不能准确标注资源的修改时间，因此使用文件内容唯一对比标识——Etag与If-None-Match。第一次请求，返回资源A+过期时间Expires+Last-Modified+Etag；后续请求，Expires未过期，使用本地缓存；Expires过期，请求服务器时带上if-None-Match(即上次请求服务器返回的Etag，Etag优先级比Last-Modified高)，服务器将if-None-Match与Etag做对比。如果相等，返回状态码304，表示资源没有修改，继续使用本地缓存；如果不相等，服务器返回最新资源A+过期时间Expires+Last-Modified+Etag）

HTTP缓存是一种用于提高网页加载速度和减少网络流量的技术。当一个网页被访问时，它的内容通常会被缓存到客户端的缓存中。下次再次访问相同的网页时，浏览器会首先检查缓存，如果内容没有过期或被修改，浏览器将直接从缓存中获取内容，而不必重新下载。

缓存控制策略：

1. Expires：响应头，代表资源过期时间，由服务器返回提供；
2. Last-Modified：响应头，资源最新修改时间，由服务器告诉浏览器；
3. if-Modified-Since：请求头，资源最新修改时间，由浏览器告诉服务器(其实就是上次服务器给的Last-Modified，请求又还给服务器对比)，和Last-Modified是一对，它俩会进行对比。
4. Etag：响应头，资源标识，由服务器告诉浏览器；
5. if-None-Match：请求头，缓存资源标识，由浏览器告诉服务器(其实就是上次服务器给的Etag)，和Etag是一对，它俩会进行对比；

1 让服务器与浏览器约定一个文件过期时间——Expires

1. 第一次请求，返回资源A+过期时间Expires；
2. 后续请求，浏览器对比当前时间是否大于Expires，如果不大于，直接使用本地缓存；如果大于，请求服务器；

2 让服务器与浏览器在约定文件过期时间的基础上，再加一个文件最新修改时间的对比——Last-Modified与if-Modified-Since

1. 第一次请求，返回资源A+Expires过期时间+Last-Modified资源最新修改时间；
2. 后续请求，Expires未过期，使用本地缓存；如果过期，请求服务器时带上if-Modified-Since(即上次请求服务器返回的Last-Modified)，服务器将if-Modified-Since与Last-Modified做对比。如果相等，返回状态码304，表示资源没有修改，继续使用本地缓存；如果不相等，服务器返回最新的资源A+过期时间Expires+Last-Modified；

3 让服务器与浏览器在过期时间Expires+Last-Modified的基础上，再增加一个文件内容唯一对比标记——Etag与If-None-Match

Last-Modified标注的最后修改只能精确到秒级，如果某些资源在1秒钟以内，被修改多次的话，它将不能准确标注资源的修改时间，因此使用文件内容唯一对比标识——Etag与If-None-Match。

1. 第一次请求，返回资源A+过期时间Expires+Last-Modified+Etag；
2. 后续请求，Expires未过期，使用本地缓存；如果过期，请求服务器时带上if-None-Match(即上次请求服务器返回的Etag，Etag优先级比Last-Modified高，毕竟更精准)，服务器将if-None-Match与Etag做对比。如果相等，返回状态码304，表示资源没有修改，继续使用本地缓存；如果不相等，服务器返回最新的资源A+过期时间Expires+Last-Modified+Etag；

HTTP和HTTPS的区别？

（1 端口：HTTP80默认端口，HTTPS443默认端口；2 安全性：HTTP明文传输不加密不安全，HTTPS使用SSL或TLS协议加密安全；3 性能：HTTPS增加加解密操作，性能稍低；4 SEO：搜索引擎更倾向于排名HTTPS的网站；）

1. 端口：HTTP的URL由”http://"起始且默认使用端口80，而HTTPS的URL由“https://"起始且默认使用端口443；
2. 安全性：HTTP是明文传输协议，数据在传输过程中不加密，容易被攻击者窃取或篡改。而HTTPS通过使用SSL或TLS协议对数据进行加密，确保数据在传输过程中的机密性和完整性；
3. 性能：由于HTTPS需要对数据进行加密和解密的操作，相对于HTTP而言，HTTPS会在一定程度上增加数据传输的延迟，因此性能稍低；
4. SEO：搜索引擎优化（SEO）方面，HTTPS对网站的排名有一定的影响。搜索引擎更倾向于排名使用HTTPS的网站，因为HTTPS能提供更好的安全性和用户隐私保护；

对称加密和非对称加密

（1 对称加密：加解密同一密钥，加解密速度快，密钥交换过程有风险如果被第三方获取安全性丧失，DES、AES等；2 非对称加密：加解密使用不同密钥，一把公开的公钥加密、一把私有的私钥解密。流程：接收方生成一对公钥和私钥，发送方使用接收方公钥对数据加密，接收方使用自己的私钥解密，即使第三方截获密文但没有私钥没办法解密）

对称加密

1 加密和解密使用同一密钥。2 优点是运算速度快；缺点是密钥交换过程有风险，密钥如果被第三方获取，安全性就会丧失。3 常见的对称加密算法有DES、AES等。

非对称加密

加密和解密使用不同的密钥，即一把公开的公钥加密、一把私有的私钥解密。安全性较高，但计算复杂，速度较慢。常见的非对称加密算法有RSA、DSA、ECC等。

非对称加密工作流程：

1. 密钥生成：接收方生成一对密钥，包括一个私钥和一个公钥。私钥用于解密加密的数据，而公钥用于加密数据；
2. 加密过程：发送方使用接收方的公钥对明文进行加密，加密后的密文只能使用接收方的私钥进行解密；
3. 传输过程：将加密后的密文通过不安全的通信渠道传输给接收方，即使第三方截获了密文，由于没有接收方的私钥，无法解密密文；
4. 解密过程：接收方使用自己的私钥对密文进行解密；

HTTPS怎么实现安全的加密传输？

（1 对称加密+非对称加密：使用非对称加密传输对称密钥，使用对称加密保证高效通信 2 流程简述：服务端生成一对非对称密钥，公钥发给客户端；客户端生成对称密钥，使用服务端发来的公钥加密，加密后发给服务端；服务端用私钥解密，得到对称密钥；从此使用对称密钥通信 3 客户端最开始如何判断收到的这个公钥是来自服务端而不是其他人冒充的：数字证书。服务端向权威机构申请一个证书来证明自己的身份，并将证书（证书中包含公钥）发给客户端，客户端收到证书后既证明了服务端的身份又拿到了公钥；4 HTTPS加密过程：客户端发起HTTPS请求，服务器发送数字证书，客户端验证证书，客户端生成对称密钥，客户端使用服务器的公钥加密对称密钥，服务器使用私钥解密对称密钥，客户端和服务器使用对称密钥通信）

HTTPS使用的是对称加密和非对称加密的混合加密算法：使用非对称加密传输对称密钥来保证安全性，使用对称加密来保证通信效率。

工作流程简述：

1. 服务端生成一对非对称密钥，将公钥发给客户端；
2. 客户端生成对称密钥，用服务端发来的公钥进行加密，加密后发给服务端；
3. 服务端收到后用私钥进行解密，得到客户端发送的对称密钥；
4. 于是通信双方就可以通过对称密钥进行高效通信了；

存在问题与解决

存在问题：客户端最开始如何判断收到的这个公钥是来自服务端而不是其他人冒充的？

解决：数字证书。服务端向权威机构申请一个证书来证明自己的身份，到时候将证书（证书中包含公钥）发给客户端就可以了，客户端收到证书后既证明了服务端的身份又拿到了公钥，于是就可以进行下一步操作了。

HTTPS加密过程：

1. 客户端发起HTTPS请求：客户端向服务器发起HTTPS请求，请求连接到安全的网站；
2. 服务器发送数字证书：服务器向客户端发送一个数字证书，其中包含了服务器的公钥和证书相关的信息。数字证书是由受信任的证书颁发机构（CA）签发的，用于验证服务器身份的可信凭证；
3. 客户端验证证书：客户端收到服务器发送的数字证书后，会验证证书的合法性和有效性。验证包括检查证书的签名是否有效、证书是否过期、证书中的域名是否与请求的域名匹配等；
4. 客户端生成会话密钥：如果证书验证通过，客户端会生成一个用于加密通信的会话密钥（对称密钥）；
5. 客户端使用服务器的公钥加密会话密钥：客户端使用服务器的公钥对会话密钥进行加密，然后将加密后的会话密钥发送给服务器；
6. 服务器使用私钥解密会话密钥：服务器收到客户端发送的加密会话密钥后，使用自己的私钥进行解密，获取会话密钥。
7. 客户端和服务器开始加密通信：客户端和服务器使用会话密钥进行对称加密和解密，保证通信数据的保密性和完整性。

上述流程存在的一个问题是客户端哪里来的数字认证机构的公钥，其实在浏览器开发时，会内置常用数字证书认证机构的公钥。

流程图如下：

HTTP状态码

	类别	原因短语
1XX	Informational（信息性状态码）	请求已被接收，正在处理
2XX	Success（成功状态码）	请求被成功接收并处理
3XX	Redirection（重定向状态码）	需要进一步的操作以完成请求
4XX	Client Error（客户端错误状态码）	请求有错误
5XX	Server Error（服务端错误状态码）	服务端在处理请求时发生错误

其他

URI和URL的区别

1. URI（Uniform Resource Identifier）是统一资源标识符，可以唯一标识一个资源；
2. URL（Uniform Resource Location）是统一资源定位符，可以提供该资源的路径信息，是一种具体的URI；
3. URI类似身份证号，URL类似家庭住址；

Cookie和Session

（1 HTTP无状态，通过Cookie和Session保持状态；2 Cookie：客户端保持状态的方法，一个字符串，服务器在响应客户端请求时将Cookie放在Set-Cookie下，客户端收到后保存Cookie，之后再请求时带上Cookie就可以被识别，分会话Cookie和持久Cookie，会话Cookie将服务器返回的Cookie保持在内存中，关闭浏览器后自动销毁，持久Cookie存储在磁盘，有效期内可被多浏览器共用；3 Session：服务端保持状态的方法，客户端登录服务器后，服务器创建对应的Session用来保存用户的会话信息，同时分配一个唯一的SessionID，服务器向客户端发送一个Cookie，Cookie中存储这个SessionID，客户端将此Cookie保存，客户端再次登录服务器时，将请求和此Cookie一起提交给服务器，服务器提取出SessionID后，找到对应的Session，继续之前的业务操作）

HTTP作为无状态协议，必然需要以某种方式保持连接状态，于是出现了Cookie和Session技术。

Cookie

1. Cookie是客户端保持状态的方法；
2. Cookie其实就是由服务器发至客户端并由客户端保存的一段字符串。为了保持会话，服务器在响应客户端请求时将Cookie放在Set-Cookie下，客户端收到后保存Cookie，之后再请求时带上Cookie就可以被识别；
3. Cookie在客户端的保存形式有两种，一种是会话Cookie一种是持久Cookie。会话Cookie就是将服务器返回的Cookie保持在内存中，关闭浏览器之后自动销毁；持久Cookie则是存储在客户端所在磁盘上，其有效时间在服务器响应头中被指定，在有效期内，客户端再次请求服务器时都可以直接从本地取出。存储在磁盘中的Cookie可以被多个浏览器代理共享；

Session

1. Session是服务端保持状态的方法；
2. Session可以存储在服务器上的文件、数据库或者内存中，也可以存储在 Redis 这种内存型数据库中，效率会更高；
3. Session的工作原理是：1 客户端登录服务器成功后，服务器创建对应的Session用来保存用户的会话信息，同时分配一个唯一的SessionID；2 服务器向客户端发送一个Cookie，Cookie中存储这个SessionID，客户端将此Cookie保存；3 客户端再次登录服务器时，将请求和此Cookie一起提交给服务器；4 服务器提取出SessionID后，找到对应的Session，继续之前的业务操作；
4. 注意：SessionID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 SessionID值。此外，还需要经常重新生成 SessionID。在对安全性要求极高的场景下，例如转账等操作，除了使用Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式；

Session的Redis存储案例

1. 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
2. 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 为SessionID；
3. 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个SessionID，客户端收到响应报文之后将该Cookie存入浏览器中；
4. 客户端之后对同一个服务器进行请求时会包含该Cookie，服务器收到之后提取出SessionID，从Redis 中取出用户信息，继续之前的业务操作；

如果客户端禁用cookie怎么办？

通过在URL中传递SessionID。

从输入URL到页面加载发生了什么

（1 DNS解析URL对应IP；2 根据IP建立TCP连接；3 发送HTTP请求；4 服务器处理请求返回数据资源；5 浏览器解析渲染页面）

1. DNS解析URL对应的IP；
2. 根据IP建立TCP连接（三次握手）；
3. 发送HTTP请求；
4. 服务器处理请求并返回数据资源：在服务端实际上还有很复杂的业务逻辑，服务器可能有多台，到底指定哪台服务器来处理请求，这需要一个负载均衡设备来平均分配所有用户的请求；
5. 浏览器解析渲染页面，发现还有一些静态资源（如CSS、JS或图片）时又会发起另外的HTTP请求，而这些请求很可能会在CDN（内容分布网络）上，那么CDN服务器又会处理这些请求；

DNS

（1 域名系统，将域名和IP地址相互映射的分布式数据库；2 浏览器输www.baidu.com，检查本地hosts文件是否有这个域名的映射关系，有则取IP地址；如果没有，查询本地DNS解析器缓存，有则取IP地址；如果没有，本地DNS服务器向根域名服务器查询，根域名服务器让本地域名服务器去查询.com顶级域名服务器，本地DNS服务器向.com的顶级域名服务器发起查询，.com的顶级域名服务器会告诉本地域名服务器去查找.baidu.com的权威域名服务器，本地DNS服务器向.baidu.com的权威域名服务器发起查询，.baidu.com的权威域名服务器告诉本地域名服务器www.baidu.com所对应的IP地址，本地域名服务器告诉主机www.baidu.com所对应的IP地址）

域名系统（Domain Name System，DNS）是将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网；

DNS是集群式的工作方式还是单点式的，为什么？

答：集群式的。比较容易想到的方案是只用一个DNS服务器，包含了所有域名和IP地址的映射，但是这种设计缺点显而易见，如果这个唯一的DNS服务器出了故障就全完了。因此为了避免这种情况，DNS系统采用的是分布式的层次数据数据库模式。

域名解析过程：

主机向本地域名服务器的查询一般采用递归查询，而本地域名服务器向根域名的查询一般采用迭代查询。

简单来说，递归查询就是：小明问了小红一个问题，小红不知道，但小红是个热心肠，小红就去问小王，小王把答案告诉小红后，小红又去把答案告诉了小明；迭代查询就是：小明问了小红一个问题，小红也不知道，于是小红让小明去问小王，小明去问了小王，小王把答案告诉了小明。

以查询www.baidu.com为例：

1. 在浏览器中输入www.baidu.com，操作系统会先检查自己本地的hosts文件是否有这个域名的映射关系，如果有，就调用这个IP地址映射，完成域名解析；
2. 如果hosts文件中没有，则查询本地DNS解析器缓存，如果有，完成地址解析；
3. 如果本地DNS解析器缓存中没有，则去查找本地DNS服务器，如果查到，完成解析；
4. 如果没有，则本地DNS服务器会向根域名服务器发起查询请求，根域名服务器会告诉本地域名服务器去查询.com的顶级域名服务器；
5. 本地DNS服务器向.com的顶级域名服务器发起查询请求，.com的顶级域名服务器会告诉本地域名服务器去查找.baidu.com的权威域名服务器；
6. 本地DNS服务器向.baidu.com的权威域名服务器发起查询请求，.baidu.com的权威域名服务器会告诉本地域名服务器www.baidu.com所对应的IP地址；
7. 本地域名服务器告诉主机www.baidu.com所对应的IP地址；

几种常见协议

1. OSPF：开放式最短路径优先。是一种基于IP协议的路由选择协议，采用Dijkstra算法来计算最短路径树；
2. ARP：地址解析协议，是根据IP地址获取MAC地址的一个TCP/IP协议；
3. HTTP：一个简单的请求-响应协议，运行在TCP之上，是在客户端和服务器之间传输文字、图片、音频、视频等超文本数据的约定和规范；

ping

ping是ICMP（网际控制报文协议（网络层的一个协议））中的一个重要应用，其作用是测试两个主机的连通性。

工作过程：

1. 向目的主机发送多个ICMP回送请求报文；
2. 根据目的主机返回的回送报文的时间和成功响应的次数估算出数据包往返时间及丢包率。

路由器和交换机的区别

1. 路由器：用于网络层，识别IP地址并根据IP地址转发数据包，维护数据表并基于数据表进行最佳路径选择；
2. 交换机：用于数据链路层，识别MAC地址并根据MAC地址转发数据帧；

网络编程

TCP编程的核心步骤

1. 客户端的connect() 函数，功能是为客户端主动连接服务器，建立连接是通过三次握手，而这个连接的过程是由内核完成，而不是这个函数完成的，这个函数的作用仅仅是通知计算机内核，让计算机内核完成TCP三次握手连接，最后把连接的结果返回。通常的情况，客户端的connect() 函数默认会一直阻塞，直到三次握手成功或超时失败才返回；
2. 服务端的bind()函数，功能是把一个本地协议地址赋予一个套接字。对于网际协议，协议地址是32位的IPv4地址或是128位的IPv6地址与16位的TCP或UDP端口号的组合；
3. 服务端的listen()函数，功能是使主动连接套接字变为被动连接套接字，使得一个进程可以接受其他进程的请求，从而成为一个服务器进程；
4. 简言之，listen()是进入监听状态，表示愿意接收连接请求（listen()函数不会阻塞，它主要做的事情是: 将该套接字和套接字对应的连接队列长度告诉 Linux 内核，然后，listen()函数就结束）。listen()之后有连接请求就将其放到队列中；
5. accept()是把新连接请求从队列中取出，建立新的socket（accept()函数会阻塞，直到取出队列中已完成的用户连接为止）。注意UDP的套接字不需要listen，只有TCP的套接字监听才要listen。UDP的套接字bind需要监听的端口就可以接收数据了；