八股文——网络篇

OutlierLi

于 2024-09-23 08:06:27 发布

阅读量1.2k

点赞数 12

分类专栏：计算机网络文章标签：计算机网络

本文链接：https://blog.csdn.net/Input_print/article/details/142441695

版权

计算机网络专栏收录该内容

1 篇文章 0 订阅

订阅专栏

八股文——网络篇

网络篇

浏览器输入URL并按下回车之后会发生什么？（超高频）

解析URL：输入URL并进行解析。输入URL后，浏览器会解析出来使用的协议、主机、端口号、所请求的资源的文件路径等信息；并构造一个HTTP请求（并且浏览器会根据请求头判断是否有HTTP缓存，并根据是否有缓存决定从服务器获取资源还是使用缓存资源）；
域名解析：DNS域名解析，将域名解析为对应的IP地址；
TCP连接建立：建立TCP连接（包括三次握手）；
发送请求报文：浏览器发送HTTP请求报文到服务器；
服务器响应：服务器处理HTTP请求并返回HTTP响应报文；
加载页面：浏览器根据接受到的报文渲染页面；
TCP连接断开：断开TCP连接（四次挥手）

DNS是什么？为什么要有DNS？

DNS是一种用于将域名转换为IP地址的分布式系统。（分别解释域名、IP地址、分布式系统、转换过程）域名符合人们的使用和记忆，但是不符合计算机的存储；IP地址符合计算机的存储但是不符合人们的使用和记忆（引出问题）；所以我们在使用和记忆时使用域名，在计算机通信时使用IP地址；

DNS为什么是分布式系统？

（首先解释集中式系统有什么不好）如果DNS是集中式系统，会有以下几个问题：单点故障、远距离集中式数据库、维护成本巨大；

单点故障：单个DNS服务器要处理所有的DNS服务，一旦故障，整个网络都会瘫痪；
远距离集中式数据库：只有单个DNS服务器，不同计算机到达服务器的距离不同，只有邻近DNS服务器的用户可以快速查询，远距离的用户势必势必有很大的时延；（甚至为了避免远距离，有些网站开启了CDN服务）
维护成本巨大：单个DNS服务器会导致低俗和拥堵的链路，造成严重时延。单个DNS服务器维护成本巨大，要频繁更新。（其次说明是如何实现分布式的）

DNS分布式系统的实现：

分层结构：从根域名服务器开始，逐级向下划分为顶级域名服务器，授权域名服务器、本地域名服务器，每一个级别的服务器都只负责维护和管理一部分域名数据；
递归查询和迭代查询：当客户端向某个DNS服务器查询域名解析时，如果该DNS服务器不负责该域名，则会向其他DNS服务器查询，最终找到负责该域名的DNS服务器来完成域名解析；
DNS缓存：域名解析未必要在DNS服务器上进行，如果DNS服务器崩溃，本地有DNS缓存，也可以用缓存来回答客户端的查询；（域名解析数据不只存储在一处，可以缓存在很多处，比如本地主机、本地路由器等）
域名区域分布：不同的域名服务器只负责自己的域名区域的管理工作；

什么是分布式系统？就是数据分成很多部分，分别存储在不同的主机或服务器；分析域名www.baidu.com，域名解析数据可能保存在本地缓存，可能保存在本地服务器缓存中，也可能同一子网中某个主机也有该域名解析，也可能保存在某些权威域名服务器，同一数据可能保存在不同地方；同样如果是blog.outlierli.ink，则保存在ink域名服务器记录的权威域名服务器中，不同数据可以保存在不同服务器；

不存在baidu域名服务器，当我们在com域名服务器中找时，会返回权威域名服务器而不是所谓的baidu域名服务器（没有二级域名服务器这一说法）！根域名服务器和顶级域名服务器并不负责具体的域名解析，根域名服务器返回域名对应的顶级域名服务器的IP地址，顶级域名服务器返回保存域名解析的权威域名服务器，在权威域名服务器上才会进行最终的域名解析；

（ps：blog.outlierli.ink中，没有独立的outlierli域名服务器，但是可以通过注册商所提供的解析服务以及分布式的域名系统架构来实现域名解析，具体而言就是注册商将域名解析信息分发到根域名服务器、ink顶级域名服务器、某些权威服务器等）

域名的层级关系你知道吗？

DNS中的域名按照"."来分割。比如www.baidu.com中有2个不同的域名：baidu，com；域名越靠近右边层级越高，比如com是顶级域名，baidu是二级域名。注意www并不是域名，而是baidu域名的子域名（子目录），子域名是域名系统中更具体地子分类，不同的子域名可以有自己的主机和资源。（比如www.outlierli.ink和blog.outlierli.ink中www和blog就是两个不同的子域名，我们可以在两个不同子域名的网站上部署不同的资源）

DNS做域名解析的过程是什么，请描述？

查浏览器缓存中有没有域名-IP地址转换关系；
查本地的HOST文件中是否有对应缓存；
查与本机相连的路由器缓存；
如果子网内没有DNS服务器，则采用ARP地址解析协议对默认网关进行查询，获取到默认网关的MAC地址，将DNS查询请求发到默认网关；
如果子网内有DNS服务器，采用ARP地址解析协议对DNS服务器查询，获取DNS服务器MAC地址，向本地的DNS服务器（互联网服务商ISP例如中国移动提供）发送查询请求；
本地DNS服务器中如果没有，则向根DNS服务器发出查询请求；根DNS服务器并不解析域名，而是告诉本地DNS解析器应该向哪个顶级域的DNS服务器查询；（比如www.baidu.com要向com顶级域名DNS服务器查询）
本地DNS解析器向指定的顶级域名服务器查询，顶级域名服务器告诉本地DNS解析器向哪个权威DNS服务器查询；（迭代查询）
本地DNS解析器向权威DNS服务器查询；权威DNS服务器会查找baidu.com对应的IP地址，然后返回给本地的DNS解析器；
本地DNS解析器将IP地址返回浏览器；并且进行缓存；
浏览器根据IP地址，与目标服务器进行连接；

DNS解析过程中的递归查询和迭代查询你清楚吗？

递归查询就是本地DNS解析器只用向上层DNS服务器发送一次查询请求，之后上层DNS服务器会自动查询下一级的服务器，并将最终结果返回本地DNS解析器（本地DNS解析器发起一次查询，收到一次返回，即可实现解析；就像递归一样，一层层自己深入，然后最后只返回结果，深入了多少层我们不关心）

迭代查询就是本地DNS解析器只是询问上层服务器一个更高级域名服务器的地址，然后自己向更高层域名服务器发起查询；（本地DNS解析器发起多次查询）

二者的适用场景不同，递归查询适用于普通用户和客户端（对普通用户来说，看上去就像只查找了一次就成功）；迭代查询适用于DNS服务器之间的通信；

HTTP的特性是什么？简述一下。

简单、灵活和易于扩展、无状态、明文传输、不安全；

简单：HTTP基本报文格式为header+body，头部信息（即请求头）也是最简单的key-value的简单文本的形式，易于理解；
灵活：HTTP协议里各种信息没有被固定死（比如各种请求方法、头字段等），允许开发人员自定义和扩展；
易于扩展：HTTP工作在应用层，下层可以所以变化，在HTTP和TCP之间添加SSL/TSL安全传输层，就是HTTPS；将TCP换成基于UDP的QUIC就是HTTPS；
无状态：服务器不会记忆HTTP的状态（解决方案Cookie技术）
明文传输：传输中的信息可以直接阅读；
不安全：适用明文传输，内容可能被窃听；没有验证通信方身份，可能遭遇伪装；无法保证报文的完整性（没有完整性校验），可能被篡改；

窃听、伪装、篡改分别是什么意思？

窃听：未经允许监视网络信息；

伪装：攻击者伪装为合法用户（包括合法客户端和合法服务器）来欺骗用户或服务方；

篡改：指修改传输过程中的数据包；

HTML、CSS、HTML、URL这些分别是什么？

HTML是页面文本标记语言，定义了网页中文本、图像等元素的展示方式；
CSS是用于定义网页样式和布局样式的语言；
HTTP是超文本传输协议；
URL是统一资源定位符，用于标识互联网上的资源，包括协议类型、域名、路径等信息，用于定位资源位置；

你对于HTTP的版本变化有了解吗？分别阐述HTTP各个版本，包括HTTPS、HTTP3等，重点在于每个版本有什么问题，下一个版本改进了什么。

HTTP/0.9：最早的版本，只支持GET方法，没有请求头，服务器只能返回HTML格式的内容（就是只能获取静态页面）

HTTP/1.0：是HTTP协议的第一个正式版本；

相对于上一个版本的改进：引入了请求头和响应头，支持多种请求方法和状态码；

存在的问题：不支持持久连接（短连接），每一次请求都要建立新的连接；（同时如果要发送下一个请求，要上一个请求的响应回来才能发送，只有上一个响应回来了，上一次连接才完成）

HTTP/1.1：

相对于上个版本解决的问题：长连接和管道网络传输，更多请求头、请求方法、状态码，更好的协商缓存判断；
- 长连接：TCP三次握手之后建立长连接，只有任何一方没有明确提出断开连接，则一直维持连接（并不只是TCP的长连接，而且还是HTTP自己的长连接，HTTP的头部字段中Keep-Alive有效）；
- 管道网络传输：客户端可以同时发送多个请求，无需等待之前的请求回来就可以继续发送请求；
- 增加了HOST请求头，使得一个服务器可以创建多个Web站点；
- 增加了新请求方法、错误响应状态码；
- 增加了新的协商缓存的缓存头（比如根据标志位判断资源有没有被修改的缓存头）
存在的问题：头部冗余、队头堵塞、没有请求优先级控制只能按照请求顺序处理和返回响应、服务器只能被动响应不能主动推送资源；
- 头部冗余：每一次请求和响应都要带有一定的“重复的”头部信息（明明已经建立好了连接，可是还是每次发送重复的信息，按理来说，一个连接内这些冗余的头部信息只用发一次即可）
- 队头堵塞：客户端改进之后可以一次性发送多条请求，可是服务端还是要一条条顺序处理，如果第一个请求要处理的时间很长，则后面的请求都会被堵塞，表现出来就是客户端发送了很多请求，可是一个响应都没有回来。
- 没有请求优先级控制只能按照请求顺序处理和返回响应：比如页面中有一个视频资源没有加载出来，而此时我们还选择登录页面，登录请求就会被视频资源请求阻塞，明明登录请求更为重要，可是我们却不能及时处理。
- 服务器只能被动响应不能主动推送资源：服务器可能已经知道了客户端想要什么资源，可是由于客户端没有请求，服务器不能主动返回，即使服务器知道了下一次推送的资源，还是要等待客户端的请求；（一般请求HTML的资源后还要请求CSS资源，如果可以主动推送CSS的资源，就可以减少请求资源的次数）

HTTP/2：基于HTTPS的，所以增加了安全性；

相对于上个版本解决的问题：编码效率提高、并发传输、服务器主动推送；
- 编码效率提高：首先使用了HPACK压缩算法对请求和响应头进行压缩，减少了头部数据量；其次将数据分割为二进制帧进行传输，增加了数据传输效率；
- 并发传输：引出了Stream的概念，多个Stream复用在一条TCP连接，并用独一无二的StreamID来区分，不同的Stream帧可以乱序发送（到达服务器后根据StreamID重组即可）；最终实现并行交错地收发请求和响应；
- 服务器主动推送：对于客户端的一个请求，服务器可以发送多个响应，即服务器可以额外推送资源；
存在的问题：队头堵塞、握手延迟、网络迁移要重新连接；
- 队头堵塞：和之前的队头堵塞不同，之前是宏观上的队头堵塞（消息和消息之间的队头堵塞，因为早到的消息堵塞晚到的消息），现在是微观上的队头堵塞（由于TCP是字节流协议，必须保证字节数据的完整和连续，所以后面字节由于前面的字节没有到只能放在内核缓冲区，不能被应用层拿到，只有等待前面的字节也到了组成完整且连续的字节流，才能被应用层拿到）；
- 握手延迟：TCP和TLS存在握手延迟；（TCP三次握手，TLS1.2四次握手（TLS1.3改进为3次握手），而且必须先TCP握手然后TLS握手，不能一起进行，最少3RTT的时延）
- 网络迁移要重新连接：如果网络发生变化（比如从wifi切换到移动数据，IP地址会变化），要重新建立TCP和TLS连接，然后才能继续通信；（这也是因为TCP协议导致的，TCP连接由【源IP地址，源端口，目标IP地址，目标端口】确定，其中的任何一个发生变化，就会导致连接断开，需要重新连接）

HTTP/3：下层的TCP协议改为了UDP协议，同时添加了QUIC协议；

由于HTTP/2存在的问题是队头阻塞，而此时的队头阻塞是由于TCP是基于字节流的协议，所以要解决字节队头堵塞，就要抛弃TCP协议，使用UDP协议；可是直接使用UDP协议也不可以，因为UDP协议是无连接的、不可靠的，所以必须在UDP和HTTP之间添加QUIC协议保证可靠性；
此外虽然UDP协议是无序的，但是QUIC协议包含TLS层的功能，TLS会保证数据包可以被有序的重组记录，确保数据的有序性；
UDP协议虽然是无连接的，但是QUIC协议可以在零延时情况下建立连接，并且QUIC的连接也支持多路复用，单个连接上可以同时传输多个数据流；此外QUIC协议还可以实现类似TCP的流量控制、拥塞控制以及重传机制；（QUIC协议补足了UDP的缺陷，同时又让UDP快速、简单、实时传输的特性得以保留）
相对于上个版本解决的问题：传输效率更高、无队头堵塞、更快的连接建立、网络迁移不需要重新连接、向前纠错机制；
- 传输效率更高：QUIC协议改进了头部压缩算法（从HPACK到QPACK），静态表的大小变大（从61项到91项）；
- 无队头堵塞：UDP协议传输数据，不用维护字节流的完整和连续，一个连接上的多个Stream之间没有依赖，一个Stream包丢了不会影响其他Stream包，所以不会发生队头阻塞；
- 更快的连接建立：UDP不需要建立连接；QUIC允许在首次连接时进行零往返时间连接建立，减少了连接延迟；
- 网络迁移不需要重新连接：QUIC协议允许网络切换时将连接迁移到新的IP地址，从而减少连接的中断时间，也不用重新建立连接；
- 向前纠错机制：每一个数据包都带有其他数据包的部分数据（数据包都带冗余），所以少量丢包可以不用重新发送，而使用其他数据包进行重组恢复；避免了数据重传；

HPACK压缩算法是什么？有什么作用？

HPACK算法时HTTP/2对于HTTP/1的改进中使用的算法；用于压缩头部；由于每次发送请求和接受响应的请求头和响应头中有很多重复的内容，影响传输效率，所以HTTP/2中用HPACK压缩算法来将高频出现在头部的字符串和字段进行压缩；

压缩过程：

对头部中高频出现的常见的字符串和字段的压缩：使用静态表编码（静态表早已经写入了HTTP/2框架中，通信双方都提前知道静态表内容，例如:path : /index.html 是一组key-value）
对于在同一个连接上，传输完全相同的HTTP头部：使用动态表编码（动态表编码时通信双方在一个连接上都维护的表，可以动态更新），动态表的大小对于服务器的性能有影响，所以不能无限增大，到达某一个大小之后服务端就会关闭连接；
- 动态编码表：客户端和服务器各自维护各自的动态编码表，双方并不知对方的动态编码表的key-value内容；收到编码后的消息，用HPACK解码；发送消息时，用静态编码表和动态编码表编码；
- 虽然双方没有发消息同步动态编码表内容，但是动态编码表再双方是一致的，只有一致才能编码解码；
- 初始时动态编码表为空；动态编码表在收发数据包中逐渐扩大；
- 双方都坚持一套动态编码表算法，虽然不对彼此的动态编码表进行同步，但是在收发彼此都知道的数据包过程中，不断扩大动态编码表；（比如动态编码表想象为一共函数key()，发送方发送报文mes1就用key(mes1)生成动态编码表内容，接收方收到mes1后也用key(mes1)生成动态编码表内容，虽然双方没有发送彼此的动态编码表进行同步，但是只要没有丢包，双方的动态编码表就一直保持同步）
- 动态编码表不一致的问题：比如某个包丢失了，而这个包中可能存在可以更新动态编码表内容的头部信息，那之后的包很可能无法解码，因为发送方的动态编码表已经更新了，接收方没有接收到，所以动态编码表没有更新，最终导致动态编码表不同步，接收方就无法解码后面的信息；（在HTTP3中改进为QPACK压缩算法）
对字符串进行哈夫曼编码来压缩；

静态编码表 + 动态编码表 + 哈夫曼编码，最终让传输效率大大提升；

讲一下HTTP/2的并发传输是如何实现的?

多路复用：允许在一个TCP连接上同时发送和接收多个请求/响应的数据流；
流Stream传输：每个HTTP请求和响应都被划分为一个或多个逻辑上的流Stream，每个流都有唯一的标识符和优先级，可以独立管理和传输，可以同时传输多个流；
头部压缩：使用头部压缩算法提高传输效率；
服务器推送：服务器可以主动推送消息，实现了服务器端的并发传输；
为Stream设置优先级：优先级高的流Stream会被优先处理；

QUIC协议是什么？怎么用QUIC协议加UDP协议实现类似TCP的可靠连接的功能？

UDP协议是简单、无序、无连接、不可靠的传输协议，数据包没有依赖关系；QUIC协议为UDP协议实现类似TCP的连接管理、拥塞窗口、流量控制、超时重传的网络特性，使得UDP协议可以在保留自己的简单、快速、实时传输等特性的同时，又实现了TCP的可靠性；

QUIC内部包含了TLS，而TCP和TLS是分层的，所以TCP握手完才能TLS握手，而QUIC和UDP结合时，UDP不需要握手，所以只用TLS握手，并且优化了TLS握手的过程，实现了近乎0时延的连接建立；

怎么实现近乎0时延？QUIC优先在第一次握手时就发送加密的应用数据，而不需要经历完整的握手过程之后才能发送数据；这样在第一次握手时发送方就可以附上请求，在第二次握手时接收方就可以做出响应，看上去数据就是0RTT建立连接；

QUIC+UDP实现近似TCP+TLS并且扩展了TCP+TLS的功能：

QUIC内部包含TLS，所以可以实现TLS的功能（包括对数据包标上顺序，在接收端根据顺序重组数据包）
连接管理：支持0RTT握手，用连接ID标识每一个连接；
会话恢复：QUIC支持连接的会话恢复，即使连接断开，也可以通过之前保存的会话密钥来快速恢复连接状态，无需重新完整的握手；
重传机制：QUIC提供了类似TCP重传的重传机制，也包括超时重传（RTO时间内未收到ACK报文）和快速重传（连续收到3次相同的ACK报文）；
流量控制：QUIC提供了类似TCP滑动窗口的流量控制机制，也是使用窗口，每个数据流都有自己的接收窗口大小，接收方根据报文的接收窗口大小来控制发送速率；
拥塞控制：也是通过拥塞窗口控制，也包括慢启动、拥塞避免、快重传等拥塞控制算法；
确认应答：虽然和TCP一样加入了确认应答机制，通过发送特定的ACK帧来实现，但有所不同；QUIC无需确认就可以发送消息；QUIC中的确认应答可以是无序的，不必等待连续的应答数据包；QUIC还支持延时确认机制，接收方可以攒够足够多的应答然后一次性发送；QUIC还可以用累积确认，即在确认应答包中包含已经成功接收的数据包序列号范围（就不要每一个不同的序列号数据包都发送一个应答）；
多路复用：允许单个连接上同时传输多个数据流；
连接迁移：即使IP地址改变连接断开，也可以通过会话密钥实现恢复连接，即连接迁移；
安全性：提供了TLS的加密机制，确保数据传输的安全；
数据恢复：每一个数据包都有其他数据包的部分内容，即使个别数据包丢失，也可以由其余数据包中的冗余数据进行恢复，无需重传；

HTTP缓存是什么？缓存的实现方式有几种？

HTTP缓存就是在浏览器访问过目标资源之后，在本地（主机或浏览器）保存一份资源副本；之后如果继续申请访问同一资源，就可以不去服务器获取，而是在本地的资源副本中获取；（甚至可以无需和服务器做任何通讯）

HTTP缓存的实现方式：强制缓存、协商缓存；

强制缓存：不问服务器，直接在本地内存中找之前的副本；如果当前时间在副本的强制缓存期以内，则直接返回到浏览器；（缓存过期后，修改本地时间，也可以实现不去服务器找而在内存中找）
协商缓存：问服务器要请求的资源有没有修改过，最近一次修改时间是什么时候，然后和本地缓存的时间比较，如果发现本地缓存没有被修改，则使用本地缓存，并更新缓存时间为当前时间；（只需要通信一次，服务器返回状态码304说明可以使用本地资源）
- 怎么知道有没有修改过，有两种方法：
  - 看服务器资源最后修改时间：本地缓存中有资源获取时间，将这个时间附到请求报文中，服务器收到后检查报文中的时间，看是否和最后修改时间一致；（有问题，即使资源内容没有改变最后修改时间也可能改变）
  - 计算哈希：本地资源计算出一个哈希值附到请求报文中发送，服务器资源也计算出一个哈希值，比较两个哈希值；（哈希值计算消耗资源，可以用摘要算法计算部分的哈希值来减少资源消耗）

副本资源和服务器资源一致性判断方式：

强制缓存：根据文件是否过期判断；（当副本创建时，会设置一个过期时间大小，通过请求资源时间和过期时间大小，计算出文件是否过期；如果本地时间修改，则可能即使过期也会使用缓存）
协商缓存：
1. 本地缓存中有一个字段记录了文件被修改时间；在询问服务器资源时附上这个时间，服务器拿到这个时间然后来决定返回304还是返回新的资源和状态码200 OK；（缺点：有时候服务器端文件即使没有被修改，也可能更新文件修改时间，比如文件名先被修改，然后再改回来，此时文件修改时间变了，可文件内容没有改变，而我们却要重新返回文件资源）
2. 基于ETag的协商缓存（比较文件指纹）：根据文件计算出一个哈希值，作为文件指纹，只要本地缓存中的文件指纹和服务器的文件指纹没有变化，则我们认为文件也没有变化；（计算文件指纹意味着多出了计算开销，如果文件大、数量多则不适合；也可以选取文件的关键部分做文件指纹，准确率下降了，可开销也下降了）

什么是对称加密，什么是非对称加密？

对称加密（私钥加密）：用相同的算法和密钥加密、解密；（密钥一旦泄露，后果很严重）

非对称加密（公钥加密）：使用一对不同但相关的密钥：公钥和私钥；公钥用于加密数据，私钥用于解密数据；如果使用公钥加密，则需要对应私钥解密；如果用私钥加密，则需要对应公钥解密；

对称加密速度快，但密钥泄露后很不安全；非对称密钥速度慢，但是安全；

HTTPS的混合加密是什么，过程是什么样的？

混合加密是指对称加密和非对称加密联合使用；（对称加密的弊端在于会话密钥泄露之后很危险，所以用非对称加密发送会话密钥，用会话密钥实现对称加密，即保证了安全性，又保证了数据通信速度）

基本过程：

客户端向服务器发送一个HTTP请求；请求建立安全连接；
服务器向客户端返回一个包含服务器公钥的数字证书；
客户端向权威机构验证数字证书的有效性，确认服务器是合法的；
客户端使用服务器发来的公钥，随机生成一个对称加密密钥作为会话密钥；
客户端用会话密钥对数据加密，然后用公钥将将加密后的数据和会话密钥一起加密后发送给服务器；
服务器用私钥解密，获取到了会话密钥，然后双方就都有了安全的会话密钥，即可在后序的过程中使用会话密钥和对称加密来实现通信；

具体实现过程中，会话密钥不会这么简单，可能用3个双方都知道的随机数来生成会话密钥而不是传输会话密钥；

服务器生成第1个随机数，然后用私钥加密后和数字证书一起发送；
客户端收到数字证书，验证后提前出公钥解密出第1个随机数；
客户端生成第2个随机数，用公钥进行加密传输给服务器；
服务器用自己的私钥进行解密，然后生成第3个随机数，将第3个随机数用私钥加密之后发送到客户端；
客户端解密出第3个随机数，此时双方都同步了3个随机数，双方都根据这3个随机数生成相同的会话密钥；
整个过程中，没有会话密钥传输；

HTTPS协议中，如何防止数据在传输过程中被篡改？

摘要算法：使用摘要算法（哈希函数）计算出传输内容的哈希值作为指纹，接收方收到消息后也计算一遍指纹，如果指纹匹配，则说明没有被篡改；（和协商缓存中的Etag文件指纹的实现类似）

数字签名：发送者对消息的摘要（摘要一般是哈希函数计算得到的）进行加密，生成数字签名；数字签名是用私钥加密生成的，而私钥只有通信双方具有，所以如果接收方能解密，则说明通信双方身份是合法的；（哈希算法和加密算法双重验证，哈希算法保证了数据没有被篡改，加密算法保证了通信双方的合法性）

HTTPS数字证书是什么？如果没有数字证书会发生什么？数字证书是如何生成的？

数字证书用于客户端对服务器的身份验证，避免有中间人阻隔在客户端和服务器之间；

没有数字证书时：如果客户端和服务器之间有一个中间人，中间人获取到服务器的公钥，然后将自己的公钥伪装成服务器的公钥发送给客户端；客户端收到中间人的公钥后，生成会话密钥，用中间人的公钥加密，然后发送给中间人，中间人用自己的私钥解密得到了客户端的会话密钥；同时中间人也将和服务器的会话密钥发送给服务器；这样，客户端和服务器感觉自己在和彼此通信，但实际上所有通信内容都是经过中间人中转的；中间人可以任意篡改消息；

数字证书生成：

服务器将自己的公钥、实体信息和签名等生成证书请求发送到数字证书颁发机构CA获取数字证书；
CA验证服务器的身份，然后用自己的私钥进行加密，生成数字证书；（数字证书包含服务器公钥、服务器实体信息、CA信息和CA数字签名等）
客户端收到服务器数字证书后，用CA的公钥（一般CA公钥内置在浏览器或操作系统中）解密，然后验证解密后信息的合法性；确定服务器的合法性；解密后即可得到服务器的公钥，即可实现和服务器通信的非对称加密；

证书信任链：CA验证机构不止一个，如何保证CA是合法的？就要有一个信任链，在信任链顶端是根CA证书，里面注册了多个合法的中间CA，这些中间CA可以颁发服务器的数字证书；（客户端验证CA也是依次验证服务器数字证书、中间CA证书、根CA证书）

HTTPS和HTTP的区别，即HTTPS在HTTP的基础上改进了什么？

HTTP使用明文传输，不安全；HTTPS使用非对称加密+对称加密的报文传输；
HTTPS在TCP三次握手之后，还要进行SSL/TLS握手，才可进入加密报文传输，握手时延长；
HTTP端口号是80，HTTPS端口号是443；
HTTPS要向权威机构CA申请数字证书用于向客户端验证自己的可信身份；
HTTPS加入了校验机制，摘要算法+数字签名避免了数据在传输过程中被篡改；

HTTPS建立连接的全过程是什么样的？

关键点：非对称加密、对称加密、数字证书、摘要算法、数字签名；

客户端向服务器发送HTTPS加密通信请求，要求和服务器建立连接；
服务器产生公钥和私钥；将自己的公钥和实体信息等发送到数字证书颁发机构CA机构，CA机构加入自己的实体信息和公钥后对所有信息打包并用自己的私钥加密，生成数字证书，返回给服务器；
服务器发送数字证书给客户端；
客户端用CA机构的公钥进行解密，验证CA机构的合法性和服务器的可信性，确认服务器是可信的。解密的结果中存在服务器的公钥；
客户端用服务器的公钥随机生成用于对称加密通信的会话密钥，并将要发送的数据内容、摘要算法生成的数字指纹、数字签名、会话密钥等用服务器公钥进行加密后发送给服务器；
服务器用自己的私钥解密，然后就获取到了会话密钥；
此后服务器和客户端就使用会话密钥进行对称加密通信；（即用发送方用会话密钥加密后发送，接收方用会话密钥解密后获取明文）

UDP和TCP的头部格式有了解吗？二者的区别是什么？

TCP比UDP复杂了很多；TCP有窗口大小字段用于做流量控制和拥塞控制；TCP的序列号用于解决网络包乱序问题，TCP的确认应答号用于解决不丢包问题，二者都用于实现TCP的可靠数据传输；

TCP的标志字段：

ACK：代表确认应答值是否有效，如果确认应答号有效则置1，无效则置0；（用于三次握手）
RST：用于重置一个已经混乱的连接，或拒绝一个无效的数据段或连接请求；（用于强制关闭连接，不经过四次挥手，适用于有一端强制关机的情况）
SYN：用于连接建立过程，请求建立一个连接；（用于三次握手）
FIN：用于断开连接，表示发送方没有数据要传输了；（用于四次挥手）
PSH：表示立即传输数据；
URG：紧急指针有效；

注意确认应答号是ACK字段，ACK标志位和ACK字段是两个东西，但是又有联系：ACK字段的值一般是序列号加上数据长度（也是期望下一个接受的数据包的序列号），在建立连接阶段，ACK字段为0，ACK标志位也为0；在服务器接受到数据包时，返回的响应中ACK字段为接受到的数据包的序列号加上数据长度，ACK标志位置为1；

各个标志位在TCP连接和数据传输时的变化是什么样的？

TCP连接建立阶段（三次握手）：
- 客户端发送SYN=1，ACK=0请求建立连接；
- 服务端接受到请求后，返回响应SYN=1，ACK=1，表示同意建立连接并收到了客户端的请求报文；
- 客户端再次发送ACK=1，表示收到了服务器的响应报文，TCP连接建立；
数据传输：
- ACK标志位一直为1，表示报文带有有效的确认应答号；
- PSH=1时，接收方要立刻传递数据给客户端；
- URG=1时，表示紧急指针字段有效，本次传输数据中有高优先级内容，需要立即处理；
- RST=1时，表示一方有异常（可能服务器关机等），不经过TCP四次挥手关闭连接，直接关闭连接；
TCP断开连接（四次挥手，服务器发起）：
- 服务器发送FIN=1表示不再向客户端发送消息；
- 客户端接收到FIN=1之后，向服务器发送ACK=1的报文表示确认收到服务器不发消息的报文；
- 等待一段时间将数据处理完成后，客户端向服务器发送FIN=1，表示客户端也不再向服务端发送消息；
- 服务端收到FIN=1之后，向客户端发送ACK=1表示确认收到FIN；服务器自动等待一段时间后（防止链路上还有消息没有到达），关闭连接；
- 客户端收到服务器的ACK之后，关闭连接；

TCP的三次握手是什么？为什么一定要三次？两次握手行不行？

为什么要握手？因为TCP是面向连接的协议，所以一定要握手；

注意客户端和服务端在三次握手过程中的状态改变：

三次握手的过程：（客户端发起）

第一次握手：客户端发送SYN=1和ACK=0，并且随机初始化序列号放在TCP首部序列号字段，发送给服务器；（客户端处于SYN_SENT阶段，服务器处于Listen阶段）
第二次握手：服务器处于Listen阶段时，监听到客户端的请求报文，然后发送ACK=1，SYN=1表示和客户端建立连接并且收到了客户端的请求报文，填写确认应答号和序列号，同时服务器转换位SYN_RCVD阶段；
第三次握手：客户端接受到服务器的响应报文，返回ACK=1，并且填写确认应答号，然后发送给服务器，告诉服务器接收到了它发送的响应报文；此后客户端状态变为ESTABISHED（已经建立连接），服务器收到客户端的报文后，状态也变为ESTABISHED；（客户端可以携带数据发送给服务端，前两次不可以携带数据，如果携带数据，确认应答号不止加一）

为什么要三次握手？为了确保通信双方都有接收和发送的能力，建立双向传输的信任链。第一次握手让服务器知道了客户端有发送的能力，第二次握手让客户端知道了服务器有接收和发送的能力（服务器收到才发送），第三次握手让服务器知道了客户端有接收的能力；三次握手之后，客户端知道了服务器有接收和发送能力，服务器也知道了客户端有接收和发送的能力；

一次握手：客户端没办法确认服务器有发送数据的能力，服务器没有办法确认客户端有接收数据的能力；

两次握手：理论上是可以建立连接的，客户端进行了一次收和一次发，服务器也进行了一次收和一次发，但是存在“半开连接”问题；客户端可以向服务器发送数据，但是服务器没办法确认客户端是否接收数据，双方也无法同步初始序列号，这可能导致数据的丢失、重复传输或乱序传输，影响数据传输的可靠性；（还会有历史连接问题）

三次握手才可以阻⽌重复历史连接的初始化(主因)：
- 如果网络阻塞，客户端发送了一个SYN=1、ACK=0的报文后被阻塞，所以没有收到服务器回应，就又发送了一个SYN=1、ACK=0的报文；
- 如果是两次握手，服务器端在收到第一个SYN报文后返回一个ACK报文，然后就进入ESTABLISHED状态（因为服务器两次握手完成），服务器就会直接向客户端发送资源（主动推送，或者询问客户端连接状态等），可服务器此时建立的连接是历史连接，发送的所有消息都不应该被客户端处理，造成资源浪费；
- 如果是三次握手，服务器在两次握手之后在SYN_RCVD阶段，不会向客户端发送资源，不会造成资源浪费；客户端收到服务器的ACK报文检查序列号发现这是一个历史报文，不应该按照这个SYN报文建立连接，所以发送RST报文来断开这个半连接，然后重新三次握手；
- 对于服务器中已经获取到了客户端的请求并回复了响应，但是没有得到客户端响应的连接，会被服务器放在一个队列中（半连接队列），而完成了三次握手的连接会放在全连接accept队列中；
三次握手才可以确保同步双方的初始序列号：
- 如果是两次握手，虽然双方都发送了自己的序列号给对方，但是服务器没办法确认客户端收到了自己的序列号，所以无法保证双方的序列号得到了完全同步；（注意确保同步和可能同步的区别，两次握手是可能同步序列号，但不是确保同步序列号）
三次握手才可以避免资源浪费（两次握手会因为历史连接造成的资源浪费）
- 如果是两次握手，服务器每一次收到SYN消息都会直接响应并进入连接状态，而如果网络堵塞有很多历史SYN消息，就会导致服务器频繁的建立连接和断开连接，造成资源浪费；

什么是SYN攻击？

攻击者用虚假IP地址伪造大量SYN请求到目标服务器，但是不完成后续的握手（虚假IP不会对服务器的响应报文进行反应），从而让服务器一直等待确认，消耗服务器资源，让半连接队列中连接的数量迅速增加，使得后续正常的SYN请求无法加入已经满了的半连接队列，使得正常的SYN请求丢失；

（就是只完成第二次握手，不完成第三次握手，导致第二次握手的队列（半连接队列）被占满，无法继续加入新的连接）

避免方式：

扩大半连接队列大小，使得可以容纳更多半连接；
修改超时重传策略，使得第三次握手失败多次后尽早丢弃无用连接；
对于新的连接无法加入半连接队列时，计算一个cookie值，作为请求报文的序列号发送给客户端，如果客户端有响应，则说明客户端不是攻击者（攻击者伪装了IP，所以不会响应），检查客户端ACK包的合法性，然后直接加入Accept连接队列而不是半连接队列；（就是第二次握手之后不加入半连接队列而直接去尝试第三次握手，本来第三次握手之前要加入半连接队列）

TCP的四次挥手是什么？为什么一定要四次？

四次挥手过程：（客户端发起）

第一次挥手：客户端发送FIN=1的报文给服务端，告诉服务端要求关闭连接；
第二次挥手：服务端收到FIN报文之后，向客户端发送ACK报文，同时进入CLOSED_WAIT状态；
第三次挥手：服务端处理完数据后，向客户端发送FIN=1的报文告诉客户端服务器可以关闭，同时进入LAST_ACK状态；
第四次挥手：客户端收到服务端的FIN报文后，回复ACK报文，服务端接收到ACK报文后关闭服务器端的连接（直接关闭）；
客户端在**等待一段时间（2MSL）**后自动关闭连接；（谁发起谁等待）

为什么一定要四次？是为了防止在关闭过程中数据丢失。客户端发送FIN报文表示不再发送数据，但是还是可以接收数据（因为网络上还可能有响应因为阻塞没有到达客户端，客户端还要接收）；服务器接收到FIN报文之后还要处理数据（服务器要处理完数据之后才能关闭）；

发送完FIN报文之后还可以接收数据，接收FIN报文之后还可以继续处理数据和发送ACK报文；

客户端要接收网络中阻塞的报文，服务器要处理已经接收的数据，都不可能说关闭就立刻关闭；（谁发起谁等待）

为什么不和TCP建立连接一样是三次握手？因为服务器发送ACK报文和FIN报文不能一起发送，要给服务器留有处理数据的时间；

在TCP四次挥手中，为什么需要TIME_WAIT状态？为什么TIME_WAIT的等待时间是2MSL？

TIME_WAIT状态是主动提出断开连接的一方在四次挥手中处于CLOSE之前的最后一个状态；

防止历史连接中的数据：网络中可能还有被阻塞的数据包正在传输，必须留有足够的时间等待网络中所有有效数据包都被接收到；（数据包有传输超时时间，所以等待时间大于数据包传输超时时间即可，2MSL足够让两个方向上的数据包都被丢弃或者被接收，避免原来连接的数据包被下一个连接接收）
等待服务器端收到ACK消息，如果服务器端没有收到ACK消息，则会重新传输FIN报文请求关闭连接，留有足够的时间让自己的ACK报文到达对方以及对方重新发送的FIN报文到达自己；（一去一回刚好2MSL时间，去指的是ACK报文，回指的是FIN报文）

MSL是报文的最大生存时间，指的是任何报文在网络上存在的最长时间，超过这个时间报文会被丢弃；

TCP的重传机制有哪些？

为什么能重传？因为发送缓存区会存储已经发送的数据，知道收到ACK报文之后才会逐渐移除缓存区的内容；（UDP发送缓存区数据会直接发送出去，不会等待ACK报文，不会重传和清除，下一条消息会覆盖缓存区）

超时重传、快速重传、SACK选择性确认、D-SACK；

超时重传：设置一个计时器，当超过指定时间（超时重传时间RTO）没有收到对方的ACK报文，则重新发送数据；（没有收到ACK报文，不代表对方真的没有收到，也有可能是收到了但是响应ACK报文丢包）

往返时延RTT：

如果RTO远大于RTT，则会严重降低了网络传输速率；如果RTO小于RTT，则可能重新发送SYN后收到了之前的ACK，超时重传就没有意义了；所以RTO应该略大于RTT，而RTT可能随着网络链路的拥塞程度发生变化，所以RTO应该是根据链路状况动态变化的；

网络链路拥塞情况是动态变化的，所以可能刚才RTT还比较小，下一次RTT就比较大了，RTT增大到了多少，我们不知道（因为发出去的SYN没有返回ACK，所以不知道是丢包了还是阻塞了，RTT也不知道变化为多少），所以如果超时重发的数据又继续超时，我们要指定RTO变化策略，TCP的策略时将RTO时间加倍；

快速重传：当收到三个相同的ACK报文时，会在定时器过期之前，重传丢失的报文段；（为什么会收到3个相同的ACK消息？因为中间有一个请求丢包，所以之后的请求返回的ACK报文是丢包之前请求的ACK报文，因为TCP的ACK报文是有序的，所以中间某个报文丢包后后面的报文的ACK没办法发送）

存在的问题：seq2丢包，所以返回三个相同的ack报文，此时重传要从seq2开始，将seq2、seq3、seq4、seq5都重传；

SACK选择性确认：在TCP头部选项字段中添加SACK字段，可以将已经收到的数据的信息发送给发送方，使得发送方知道中间哪个数据包没有收到，只重新发送丢失的数据包；

D-SACK：使用SACK告诉发送方哪些数据被重复接收了；如果发送方没有接收到ACK消息，可能是请求报文丢包接收方没有收到，也可能是ACK报文丢包或网络阻塞；如果只是ACK报文丢包或网络阻塞，则无需重新发送消息；所以使用SACK告诉发送方重复接收的数据，就不会因为ACK报文丢包而继续重发消息；

ACK丢包：

网络延时：

我们的目的是接收方收到数据，而不一定是发送方接收到ACK消息，所以只用确保数据可靠地到达接收方即可；

TCP的流量控制机制有哪些？

滑动窗口、拥塞窗口、慢启动、拥塞避免、快速重传；

滑动窗口：TCP使用滑动窗口来控制发送端和接收端之间的数据流量，避免发送过多数据导致接收端无法处理或溢出；

拥塞窗口：防止网络拥塞而设置的，限制发送端发送数据的速度，避免网络拥塞而引起的丢包和延迟；

慢启动：控制拥塞窗口大小的一种策略；在TCP刚建立连接时，会以较小的拥塞窗口发送数据，然后以指数级扩大拥塞窗口，知道扩大到适当大小；

拥塞避免：控制拥塞窗口大小的一种策略；一旦出现拥塞，TCP就会进入拥塞避免阶段，通过线性增长方式扩大窗口。直到网络拥塞程度减轻；

快速重传：控制拥塞窗口大小的一种策略；当检测到丢失的报文段时，立即重传；

TCP的滑动窗口是什么？

为什么要有滑动窗口？如果不使用滑动窗口，每一次发送端发送完一个SEQ请求报文之后，必须等待对应的ACK报文到达之后，才能继续发送SEQ报文；会导致数据往返时间越长，网络吞吐量越低的缺点；（一个一个发送请求，每次发送请求时必须保证之前请求的响应已经到达）

滑动窗口的优点：

可以连续发送多个TCP报文段；
如果发送的多个Seq报文段中有Ack报文丢失，也可以根据后面的Ack报文段判断是Seq报文丢失还是Ack报文丢失；（如果Seq1，Seq2，Seq3发送之后只收到了Ack1，Ack3，则我们可以根据收到Ack3判断出接收端收到了Seq2，只是Ack2丢包了，所以可以不用重传）

窗口大小：一般是根据接收方的缓冲区大小决定的，TCP头部的window字段可以告诉发送方接收方的缓冲区大小，然后发送方根据window字段设置滑动窗口大小；

滑动窗口的滑动：滑动窗口大小如果为15，在收到前5个Seq报文对应的Ack报文之后，窗口会向右滑动5个单位，这就是滑动窗口的滑动；

滑动窗口的实现：在数据结构中，滑动窗口的实现使用是双指针法，一个指针指向滑动窗口的起始位置，一个指针指向滑动窗口的结束位置；这里发送方滑动窗口使用三指针法，两个绝对指针和一个相对指针；

SND.WND是滑动窗口的大小；
绝对指针SND.UNA指向已经发送但是没有收到ACK报文的第一个字节的序列号；
绝对指针SND.NXT指向还没有发送但是可以发送的范围的第一个字节的序列号；
相对指针：指向**#4的第一个字节，即未发送并且不可以发送的第一个字节的序列号，是SND.UNA加上SND.WND大小的偏移量**，指向滑动窗口的最后一个元素的下一个字节的序列号；

接收方滑动窗口使用双指针，一个绝对指针指向期待从发送方接收的下一个数据字节的序列号，一个相对指针指向未收到数据且不可以接收的数据的第一个字节的序列号；

接收方滑动窗口大小和发送方滑动窗口大小并不是严格相等的；因为滑动窗口并不是一成不变的，如果应用程序处理数据速度非常快，滑动窗口大小就可以大一点，而且滑动窗口大小要通过报文中的window字段告诉接收方，所以存在时延；所以接收方滑动窗口和发送方滑动窗口只是近似相等；

TCP流量控制的基本原理是什么？

滑动窗口机制（滑动窗口机制的整个过程，包括滑动窗口大小、移动过程、动态调整等）

TCP连接建立之后，在数据传输过程中，接收方会根据自己的缓冲区大小和应用程序从缓冲区读取数据的速度，在TCP报文的window字段设置滑动窗口的大小，然后告知发送方滑动窗口的大小；
在数据传输过程中，滑动窗口的大小可以根据接收方接收数据的情况动态调整；
发送速率控制：如果滑动窗口大，说明接收方处理数据速度快，发送方则可以加快发送速率；如果滑动窗口小，说明网络拥塞或者接收方处理数据速度慢，则发送方可以减缓发送速率；

TCP拥塞控制机制是什么？拥塞窗口是什么？

网络拥塞，导致大量数据包重传，大量数据包重传，加重了网络拥塞，最终一直恶性循环，导致数据包堵塞了整个网络链路；所以拥塞控制非常有必要；

拥塞窗口cwnd：

拥塞窗口根据网络拥塞程度变化，由发送方和接收方共同维护；
- 发送窗口的值要根据接收窗口（滑动窗口）和拥塞窗口共同决定，具体而言swnd = min (cwnd, rwnd)，其中swnd时发送窗口大小，cwnd是拥塞窗口大小，rwnd是接收窗口大小；
cwnd根据网络拥塞程度变化，网络拥塞时cwnd减小，网络不拥塞时cwnd增加；

拥塞窗口常见的算法有哪些？

慢启动、拥塞避免、拥塞发生（重传机制）、快速恢复；

慢启动：一点点提高发送数据包的数量，即一点点提高拥塞窗口大小；当发送方每收到一个ACK之后，拥塞窗口cwnd的大小就会加1；（虽然是加1，但是发包个数是指数性增长，所以窗口大小也是指数增长）

不可能一直指数增长——门限状态变量ssthresh：

当cwnd < ssthresh时使用慢启动算法指数增长，当cwnd > ssthresh时使用拥塞避免线性增长；

拥塞避免：每收到一个ACK之后，cwnd增加1/cwnd；（发包个数变为线性增长）

发包个数依旧在增长，当增长到一定程度，就会发生拥塞，进入拥塞发生阶段；

拥塞发生算法：网络拥塞，发生丢包，要进行数据包重传，选择合适的重传机制；重传机制有两种，超时重传和快速重传；超时重传是如果在超时重传时间RTO内没有收到ACK报文，则重新传输数据包；快速重传是指如果连续收到3个相同的ACK消息则重新传输数据包；

拥塞发生	`ssthresh`门限值和`cwnd`拥塞窗口大小	之后的算法	状况
超时重传时的拥塞窗口策略	先`ssthresh = cwnd/2`，然后`cwnd = 1`	慢启动	RTO时间内没有收到ACK，状况很糟糕，之间将`cwnd`设置为1
快速重传时的拥塞窗口策略	先`cwnd = cwnd/2`，然后`ssthresh = cwnd`	快速恢复，如果快速恢复成功进入拥塞避免	收到三个相同ACK，至少ACK还能收到，状况没有那么糟糕

快速恢复：在快速重传之后进行快速恢复；（连续三个相同ACK报文，网络整体拥塞程度可以接收，所以只要能重发丢包数据成功，即可继续使用拥塞避免策略）

拥塞窗⼝ cwnd = ssthresh + 3 （ 3的意思是确认有3个数据包被收到了，即对应连续3个相同ACK包）；
重传丢失的数据包；
如果还是收到重复的ACK，则cwnd增加1（虽然不是想要的ACK，但是还是收到ACK了）
如果收到新数据的ACK，cwnd = ssthresh，说明恢复过程结束，可以继续进入拥塞避免状态；

网络层IP和数据链路层MAC的功能区别，IP地址和MAC地址区别是什么？

MAC实现了两个直连的设备之间的通信，IP可以在两个没有直连的设备之间实现通信；在网络数据包传输过程中，源IP地址和目标IP地址在传输过程中不会变化，但是源MAC地址和目标MAC地址一直在变化；

MAC只关心局部的数据传输，即下一跳走哪；而IP关心全局的而数据传输，即从哪到哪；IP指明了起点和终点，MAC指明了起点到终点的每一个站台怎么走；

IP地址分类，以及分类过程是什么，各类IP地址的功能是什么？

IP地址被分为5类（ABCDE类IP地址），各类IP地址分类号用哈夫曼编码区分；

其中ABC类IP地址有主机号，可以用于主机IP；D类和E类没有主机号，不能用于主机IP；

类别	IP地址范围	最大主机数
A	0.0.0.0~127.255.255.255	16777214
B	128.0.0.0~191.255.255.255	65534
C	192.0.0.0~223.255.255.255	254

注意主机号全0和全1并不能作为主机IP，所以求最大主机数要减去这两个地址；

主机号全0：用作标识当前子网的网络地址；即使之后不再划分子网，也可以将整个类别的网络当成一个子网，主机号全0的IP地址就是这个大的子网的网络地址；如果向这个IP地址发送数据会被路由器丢弃；

主机号全1：表示该IP地址是广播地址，发送到该IP地址的数据报，将会被网络中所有主机接收；即向该IP地址发送数据，路由器会转发数据到网络中所有主机；

回环地址：127.0.0.1，一般也不分配给网络中的主机，但是计算网络最大主机数时将回环地址也算了进去。这是因为回环地址一般是由操作系统内核直接处理，而不用于网络通信；（操作系统发现是回环地址之后，就会直接将数据包给本地处理，不会发送到网络上或者路由器上）

D类地址：用于多播；

E类地址：预留的分类，暂时未使用；

类别	IP地址范围	用途
D	244.0.0.0~239.255.255.255	IP多播
E	240.0.0.0~255.255.255.255	预留

IPv4地址分类的缺点：C类地址包含的主机数只有255个太少，B类地址包含的主机数又太多；

无分类IP地址CIDR技术怎么实现？

不再有分类地址的概念，而是直接将32比特的IP地址分为两个部分，网络号和主机号；

用子网掩码来区分网络号和主机号；

表示方法：IP地址/子网掩码位数（子网掩码位数表示了网络号的长度）

CIDR路由表上包含了所有子网的IP地址范围和对应的子网掩码；

广播地址是什么？广播地址的分类是什么？

广播地址指的是主机号全1的IP地址，广播地址分为本地广播和直接广播；

本地广播：源IP地址和目标广播地址在同一个子网内，此时源IP地址向广播地址发送数据包，会直接发送到子网内所有主机上，而这个广播地址的IP包会被路由器屏蔽（都不会经过路由器），不会到达子网外的链路上；

直接广播：源IP地址和目标广播地址不在一个子网内，此时源IP地址向广播地址发送数据包，会发送到路由器，然后路由器转发到目标广播地址子网的所有主机上；

分类依据：在同一个子网内的通信不需要经过路由器进行转发。同一个子网内的设备使用相同的网络前缀，因此它们可以通过 ARP 协议（地址解析协议）将 IP 地址直接映射为 MAC 地址。这样，设备就可以直接将数据帧发送到目标设备，而不需要经过路由器。所以同一个子网上的广播地址不需要经过路由器转发，不同子网上的广播地址要通过路由器转发；

直接广播的不安全性：直接广播的范围更广，可能造成扩散恶意软件等安全隐患所以很多路由器在要求直接广播时都设置为不转发）

什么是多播地址？

D类地址是多播地址；多播地址用于将包发送给特定组内的所有主机；（主机可以自由的加入某个组当中）

直接广播由于安全性的考虑，很多路由器拒绝转发，所有如果一个主机想向另一个子网内所有主机发送数据，当广播没办法穿透路由时，就要使用穿透路由的多播；

多播地址字段划分组：

224.0.0.0 到 224.0.0.255：保留的多播地址，用于本地信令广播（即不经过路由，局域网内）。
224.0.1.0 到 238.255.255.255：可供组织使用的全局作用域多播地址。（即可以用于互联网上，可以经过路由转发）
239.0.0.0 到 239.255.255.255：用于临时使用的组播地址（包括 GLOP 地址，仅在本地范围内有效）。

注意区分主机地址和多播地址，多播地址按照组划分，任何一个主机都可以发送数据到一个已经存在的多播组；任何一个主机都可以向网络中发送多播数据报，只要知道目标多播组的地址即可。主机可以自己申请一个未被占用的多播组地址并加入，或者向已知的多播组地址发送数据。

举例说明：

好比一个学校中不同班级的学生，如果你要实现通知其他班级的篮球社学生去操场，就要先通知各班的班长，然后通过班长通知班里所有学生篮球社在操场集合，班级中篮球社的同学收到消息后自然去操场集合，这就是直接广播，每个班级好比一个子网，班长就是网关，负责传递消息到子网中。
如果班长就是不理你，不转发你的通知，觉得明明是篮球社几个人的事情，为什么要顺带通知全班同学，万一有些女同学知道了篮球社在操场集合也偷跑去，多危险！这就是直接广播受到路由器阻拦，路由器不转发广播消息。
此时你就可以使用组播，即将所有篮球社的学生不管是哪个班的都拉到一个组中，通过发送通知到组中实现了跨班的一对多的信息传递；（虽然也要经过班长，而且班长还要像个神经病一样逮住班里每个同学问你是不是篮球社的，如果是才会告诉他操场集合，班长就是这么任劳任怨保护女同学）

子网划分是什么？子网掩码如何实现网络号和主机号的划分？

为什么要分离主机号和网络号？因为如果在两个主机进行数据通信时，如果网络号相同，则说明在同一子网内，不需要进行路由转发，所以不用将数据包传递给路由器转发，直接发送给目标主机；如果网络号不同，则需要先将数据包转发给路由器；路由器也要根据网络号进行转发；

什么是子网划分？子网划分实际上是将主机号划分为子网网络地址和子网主机地址；

子网划分的好处是什么？

减少广播域的范围；（不划分子网，192.168.255.255广播，划分子网192.168.1.255，广播范围小了很多）
实现分散和隔离网络流量，避免不必要的数据泄露；
更容易管理和维护，不必要管理整个网络，只用单独对各个子网维护；
更有效的利用IP地址；

子网掩码和 IP 地址按位计算 AND，就可得到网络号（网络地址+子网网络地址）。

划分后子网主机地址全0用作子网网络地址，全1用作子网广播地址；

公有IP地址和私有IP地址是什么？

如果需要接入互联网，就要公有IP地址；如果只是在局域网内使用，则一般是私有IP地址；公有IP地址全球唯一，私有IP地址可以重复，公有IP地址可以在互联网中使用，私有IP地址只能在规定的局域网中使用；

IP路由转发的过程是什么？

在IP数据包中解析出目标IP地址；
查找主机路由控制表，找到相同网络地址的路由器的IP地址（如果找不到则转发到0.0.0.0/0默认网关），将IP数据包转发到该路由器；
路由器接收到IP数据包之后，查路由器的路由控制表，找到相同位数最多的网络地址（最长匹配），然后将数据包发送到该网络地址；
继续转发，直到转发到目标IP地址（注意转发过程中源IP地址、目的IP地址都不会改变，但是源MAC地址和目的MAC地址都会改变）

注意如果目标IP地址是127.0.0.1，操作系统内核会直接解析识别为回环地址，直接在本地处理IP数据包，不会将IP数据包发送到网络；

IP分片发生在哪一层？分片发生在哪？重组发生在哪？分片的弊端是什么？

当我们确认了下一跳转发的IP地址，就将IP数据包交到数据链路层，由于不同数据链路的最大传输单元MTU不同，所以在IP数据包大于MTU时要对IP数据包继续分片，分片后然后分别传输；

分片发生在哪？分片可能发生在链路上任何一个节点，因为不同链路的最大传输单元MTU不同，可能传着传着MTU变小，又要分片；

重组发生在哪？重组只能发送在目标主机，即路由器不会因为MTU变大而合并数据包；

如果一个数据包中某一个分片丢失，则整个数据包报废。所以如果我们使用TCP传输，则尽量在传输层就对TCP数据包分片（TCP有重传机制）从而避免在数据链路层的分片；如果使用UDP协议，则尽量让每一个IP数据包都小于MTU，避免分片；

介绍一下IPv6协议。IPv6和IPv4的区别是什么，解决了IPv4的什么问题？

IPv6地址实现了更多的地址，更好的安全性和扩展性；但是和IPv4无法兼容；

相对于IPv4的改进：

更多的可分配地址，无需担心公网IP不够用；
没有DHCP服务器也可以自动分配IP地址；
包头首部长度固定为40字节，去掉了包头校验和，简化首部结构，减轻了路由器负担；
有防止伪造IP地址的网络安全功能已经防止线路窃听功能；

实现方式：128位，每16位作为一组，用冒号隔开；

虽然位数变多，但是编码方式可以改善：比如出现连续的0的时候可以用两个冒号表示（一个IP地址中只容许出现一个连续的两个冒号），例如FEDC:0000:3210:0000:0000:0000:3210可以表示为FEDC:0000:3210::3210；

和IPv4地址一样，通过前几位来表示IP地址的种类：（IPv6地址种类有单播地址、组播地址、任播地址，没有广播地址）

三种单播地址：

链路内单播：不经过路由器，直接在同一链路传输；
内网单播：使用唯一本地地址，相当于IPv4的私有IP；
全局单播：用于互联网通信，相当于IPv6的公有IP；

IPv4和IPv6的首部比较：

IPv6取消了校验和字段，因为在数据链路层和传输层都会校验，所以没必要在网络层IP数据包中也校验；同时取消了分片和重组，IPv4的分片导致了某个分片丢失一整个报文都要丢弃，使得传输效率大大降低，IPv4的处理方法是尽量在TCP数据报就分片，而不是IP分片，而IPv6直接不允许中间路由器分片，分片操作只能在源主机，重组只能在目标主机，大大提高了路由器的转发效率；还取消了可选字段，让首部变成了固定40字节，可选字段可以放在Next Header指向的Body中；

ARP协议是什么？RARP协议又是什么？

ARP地址解析协议：根据IP地址查询到MAC地址；

RARP协议：根据MAC地址查询IP地址；

ARP协议实现过程：（广播ARP请求）

主机根据IP数据包解析出目的IP地址，然后查主机路由表，找到和目的IP地址相同的网络号的IP地址（或最长匹配的IP地址，如果都找不到用默认网关）作为下一跳IP地址；
主机在子网内广播发送ARP请求，ARP请求中包含了下一跳IP地址；
子网内所有主机获取到ARP请求后，解析出下一跳IP地址，然后和本机地址比较，如果相同，则返回带有本机MAC地址的ARP响应；如果没有，则不回复；
主机收到ARP响应，获取到了下一跳的MAC地址，同时操作系统一般会将ARP获取到的MAC地址和IP地址一起缓存起来；

RARP协议实现过程：（子网中获取MAC地址对应的IP地址）

需要在子网网络中假设一台RARP服务器，设备将自己的MAC地址和IP地址注册在RARP服务器上；
主机发送RARP请求包到RARP服务器，其中包含要询问的MAC地址，RARP服务器收到请求后回复RARP响应包，其中包含MAC地址对应的IP地址；

DHCP动态分配IP地址的过程是什么？

由于没有在分配IP地址之前主机没有IP地址，所有和DHCP服务器的通信中使用的都是广播地址（全1）和子网网络地址（全0）来实现临时通信；

开始时，客户端没有IP地址，也不知道DHCP服务器的IP地址；客户端发起DHCP DISCOVER发现报文（目的IP地址255.255.255.255:67，源IP地址0.0.0.0:68），使用UDP向整个网络内广播；
网络内的DHCP服务器收到客户端发送的DHCP DISCOVER发现报文，然后同样向网络内使用UDP协议广播DHCP OFFER提供报文，该报文携带可租约的IP地址、子网掩码、默认网关、DNS服务器以及IP地址租约期限等内容；
客户端收到DHCP OFFER提供报文（可能有多个DHCP服务器发送多个DHCP OFFER提供报文），从中选择一个服务器，向服务器发送DHCP REQUEST请求报文；
DHCP服务器收到客户端发送的DHCP REQUEST请求报文，然后回复DHCP ACK应答报文，其中包括DHCP服务器地址和配置信息（IP地址、租期等）；
客户端获取到IP地址，此时可以通过该IP地址继续通信（注意通信不需要经过DHCP服务器，DHCP服务器已经将该IP地址分配了）
如果IP地址租约到期，客户端可以向DHCP服务器发送DHCP REQUEST请求报文续租；
如果DHCP服务器返回DHCP ACK则续租成功，如果返回DHCP NACK则续租失败，客户端要停止使用租约的IP地址；

总体来说，就是先广播找到DHCP服务器，然后DHCP服务器告诉主机可以用的IP地址，主机选择一个IP地址告诉DHCP服务器我要了，DHCP服务器收到后分配资源给主机；

注意全部过程中广播都使用UDP协议，原因：UDP简单，面向数据报，不需要建立连接，可以快速发送数据报；在广播过程中，数据包需要在局域网内传输到所有主机，由于广播环境的不可靠性，要实现TCP可靠传输的成本大，所以选择UDP协议；

DHCP中继代理是什么？解决了什么问题？

如果每一个子网中都设置一个DHCP服务器则成本太大，如果多个子网可以共用一个DHCP服务器，则成本低，并且可以更好一起管理子网的IP地址分配；（不同网段的IP地址分配可以由一个DHCP服务器统一管理）

客户端广播DHCP数据报都会被中继代理器单播转发到路由器，然后路由器转发到DHCP服务器；DHCP服务器发送的数据报会转发到路由器，然后从路由器转发到中继代理，中继代理广播到客户端；

NAT网络地址转换协议是什么？解决了什么问题？缺点和解决缺点方法是什么？

⽹络地址转换NAT的⽅法，再次缓解了 IPv4 地址耗尽的问题。简单的来说NAT就是同个公司、家庭、教室内的主机对外部通信时，把私有IP地址转换成公有IP地址；（可以简单理解为，局域网内使用私有IP，当和互联网通信时，再转换为公有IP+端口号）

每个主机都有一个局域网内唯一的私有IP，同时整个局域网可以共用一个公有IP，主机A和互联网通信时，将私有IP转换为公有IP，同时运行在A端口；主机B和互联网通信时，将私有IP转化为相同的公有IP，同时运行在B端口；不同的私有IP转换为相同的公有IP但是端口号不同；

私有IP+端口号转换为公有IP+端口号的表是NAT转换表，在NAT路由器上自动生成；在TCP首次连接发送SYN报文后生成，在收到关闭连接发出FIN的ACK报文后删除；

缺点：

外部无法主动和私有IP地址网络内主机建立联系，因为只有主机发出TCP连接请求后才会生成NAT转换表，外部主机要联系主机时，没有NAT转换表，所以主机没有公有IP地址不能通信；
一旦NAT路由器重启，所有TCP连接全部要重新连接（因为NAT转换表要重自动生成）
转换表的生成和地址转换都会产生性能开销；

解决方案：

使用IPv6地址，每个主机都设置一个公网IP（不用担心耗尽，可以放心分配）；
使用NAT穿透技术：主机自动发现自己处于NAT路由器下，自动获取NAT设备的公有IP并自动建立端口映射，这样主机就直接和公网IP+端口绑定了（之前必须在主机发送数据到NAT路由器后，路由器负责地址映射，现在没发送数据到路由器已经自己映射了）

ICMP互联网控制报文协议是什么？有什么功能？

ICMP协议是IP协议的补充（也可以认为ICMP协议时IP协议的子协议），我们将报文发送出去之后，经常会遇到各种问题，比如某个链路阻塞了，某个路由出错了，或者某次ARP协议出错等等，如果我们只用成功传输和没成功传输两个角度分析，就会发现死的不明不白；我们必须知道传输过程中发生了什么，所以需要ICMP协议来在传输过程中发出消息；

ICMP的功能：确认IP包是否成功送达⽬标地址、报告发送过程中IP包被废弃的原因和改善⽹络设置等。在IP通信中如果某个IP包因为某种原因未能达到⽬标地址，那么这个具体的原因将由ICMP负责通知（ICMP消息会使用IP协议发送）。

ICMP可以分为两类：查询报文类型和差错报文类型；

查询报文类型：用于诊断的查询消息；

差错报文类型：用于通知出错原因的错误消息；

当我们ping一个IP地址时，会发生什么？

用户在命令行输入Ping命令，Ping命令创建一个ICMP Echo Request回送请求查询报文，其中包含一个序列号和时间戳等信息。该数据包的目的地址是我们Ping的IP地址；
通过IP协议，将ICMP Echo Request数据包发送到网络上，进行传输；
如果ICMP Echo Request到达目的地址，则目标主机返回一个ICMP Echo Reqly回送应答查询报文，从目标主机发送到源主机；
如果中间发送了意外，根据差错类型返回ICMP差错报文；
当Ping命令收到ICMP返回的报文之后，根据报文内容显示回应信息，并计算往返时间RTT等相关信息；

Ping命令在传输层并没有使用相关协议（比如UDP、TCP等），本身是基于网络层的ICMP协议实现；Ping命令是用来测试主机之间的连通性和网络延迟，它本身是一个网络诊断工具而不是一个应用，所以并没有传输层使用的协议；

IGMP因特网组管理协议是什么？使用组播地址时，如何将主机分在一组？

分组是由路由器进行管理的，路由器内部有一张IGMP路由器表，路由器根据该表转发组播包到对应的主机中；

主机可以向路由器发送IGMP报文申请加入或退出组播组；当主机加入组播组之后，路由器就会记录IGMP路由表；如果组播发送端的组播数据包发送到路由器，路由器就会根据IGMP路由表来转发组播包到相应的主机；

IGMPv2的工作机制：

常规查询和响应机制：
- 路由器周期性发送IGMP常规查询报文到同一网段所有路由器和主机；
- 主机收到IGMP常规查询报文之后，会设置一个随机的计时器，在计时器没有结束之前不会发送IGMP成员关系报文，如果计时器结束并且同一组内其他主机没有发送IGMP成员关系报文，则发送IGMP成员关系报文到整个组；
- 路由器收到IGMP成员关系报文后，将该组播组加入IGMP路由表，后续如果收到该组播组的报文，路由器就会转发；
- 注意：IGMP成员关系报文理论上只要发送一次即可，它只是让路由器知道它管理的主机中存在该组播组的成员，它需要转发该组播组的信息，并没有告诉路由器往哪转发，往哪转发要看IGMP路由表；（万一组内成员都关机了，路由器没必要转发，所以常规查询就是确认组内还有主机存活）
离开组播之后的工作机制：
- 离开组播后，网段中还有该组播组：
  - 主机发送IGMP离组报文到该网段所有路由器；
  - 路由器收到报文后，连续间隔发送IGMP特定组查询报文，确认网络中是否还有该组的成员；
  - 网段中该组成员收到IGMP特定组查询报文后立即响应，路由器发现网络中还有该组成员，则继续转发该组播组的数据包；
- 离开组播后，网段中没有该组播组：
  - 即IGMP特定组查询报文没有得到响应；一段时间后，路由器认为网段中没有该组成员；
  - 路由器不会再转发该组播组的任何数据包；

组播地址没有主机号，不是主机IP地址！组播地址一般使用UDP协议，即机器使用UDP发送数据时，目标IP地址一栏填的是组播地址，所有在该组内的所有主机都能收到数据包；

而加入和离开组播，都是由socket的一个接口实现的，主机IP地址并不会改变；（一台主机可以既有IP地址，也可以有组播地址）

交换机的作用？路由器的作用？路由器和交换机的区别？

交换机：交换机并不能将数据包转发出子网，将数据包转发到同一子网内的主机、交换机或路由器；交换机基于以太网设计，交换机没有网卡，所以也就没有MAC地址，工作在OSI模型的数据链路层MAC层（从下往上第二层），所以也叫二层网络设备；

交换机的工作流程：

电信号到达网线接口，交换机接收电信号并转换为数字信号；然后对数据包进行校验，如果校验无误，则放入交换机的缓冲区；
在交换机的缓冲区中的数据包，交换机会查询数据包的目标MAC地址，然后在自己内部存储的MAC地址表中查找该MAC地址；
MAC地址表记录了主机的MAC地址和交换机的端口的对应关系，以及一些控制信息；
如果在MAC地址表中找到了目标MAC地址，则交换机将数据包转换为电信号发送到目标MAC地址对应端口上，经由该端口传递到目标主机；
如果MAC地址表中没有找到目标MAC地址，则向除了源端口外所有端口发送该数据包，如果发送之后收到了某个主机的响应，则将该主机的MAC地址和交换机端口号写入MAC地址表；
如果目标MAC地址为 FF:FF:FF:FF:FF:FF（代表广播地址），则交换机直接向除了源端口外所有端口转发数据包；

路由器：路由器负责接收数据包或转发数据包，转发到下一个路由器或者目标设备（只有路由器可以转发出子网，交换机不能）；路由器基于IP设计，端口有IP地址和MAC地址（和网卡一样）；路由器工作在OSI模型的网络层（从下往上第三层），所以也叫三层网络设备；

路由器的工作流程：

电信号到达路由器的网线接口，路由器将电信号转换为数字信号，然后进行校验（和交换机一样，接收后负责校验），查询数据包的MAC地址，看是否和自己的MAC地址一致（交换机不需要，交换机都没有MAC地址）；如果一致，则放在自己的缓冲区；
丢弃MAC地址头部（每一跳，IP地址不会改变，MAC地址都会改变）；
根据报文中IP头部中的目标IP地址进行转发；首先提取出目标IP地址，根据目标IP地址查询出网络号，然后查询路由表判断转发目标；
如果路由表查询命中，且子网掩码不为空，则转发到路由表中对应网络号的路由器（转发之前也要查询MAC地址，因为转发靠的是MAC地址而不是IP地址）；
如果命中后子网掩码为空，则说明已经抵达终点，路由器只需要看目标IP地址和自己哪一个端口上的IP地址一致，然后转发；（或者将目标IP地址使用ARP协议广播出去查询到对应的MAC地址然后转发，或者查ARP缓存）
如果路由表查询没有命中，则有几种处理方法：使用默认路由0.0.0.0/0、发送ICMP错误信息、重新路由计算等；
获得了MAC地址就可以转发出去了；修改MAC头部后添加到数据包中（校验码也要重新计算修改）

主机——数据包——交换机——路由器——路由器——…——路由器——交换机——目标主机；

Linux网络协议栈有哪些？层次关系是什么样的？

应用程序通过系统调用来实现和Socket的数据交互；Socket层之下依次是传输层、网络层、网络接口层；

在Linux系统中，什么是Socket层？

在Linux操作系统中，Socket层是在网络编程中提供的一种抽象接口，用于实现网络通信。Socket层允许应用程序通过网络套接字（socket）在不同主机之间进行通信，可以实现不同主机之间的数据传输和通信。（操作系统中，任何都是文件，所谓通过Socket通信，本质也不过是读写一个名为Socket的数据结构）

Socket层提供了一种类似于文件I/O的接口，应用程序可以通过套接字在网络上发送和接收数据。开发人员可以利用Socket层的API来实现各种网络应用，如网络服务器、客户端、实时通信应用等。

在Linux系统中，Socket层位于操作系统内核空间，负责处理网络通信的底层细节，包括建立连接、数据传输、错误处理等。应用程序通过Socket接口与Socket层进行通信，Socket层负责将数据传输到网络中的对应目标。

Socket层是通过网络套接字提供的接口，使应用程序能够在网络上进行数据通信和交换。

Linux收发网络包的流程是什么？

发送网络包：

应用程序通过系统调用来创建Socket套接字（用户态陷入内核态中的Socket层，应用程序根据Socket层提供的API创建Socket套接字，本质是获取到一个文件描述符来读写Socket所在的内存区域）；
应用程序通过Socket层提供的API将应用层数据拷贝到Socket发送缓冲区中（Socket发送缓冲区是Socket套接字的一部分，Socket套接字是一个数据结构）；
网络协议栈从Socket发送缓冲区中取出数据包，并按照TCP/IP协议从上层向下层逐层处理；
传输层：如果是使用TCP协议，则为数据包增加TCP包头，然后交给网络层（也可能在该层分片来避免IP包分片）
网络层：增加IP包头；通过查询路由获取到下一跳的IP地址，并按照MTU（数据链路最大每次传输的报文大小）进行分片；
网络接口层：根据ARP协议查询下一跳的MAC地址，然后增加包含MAC地址的帧头，包含帧校验序列FCS的帧尾；
将处理后的数据包添加到发包队列中；
触发软中断，网卡驱动程序处理中断，通过DMA技术从发包队列中取出数据包，然后放入硬件网卡的队列Ring Buffer中（Ring Buffer是一个环形队列缓存区）；
物理网卡将数据包转换为电信号发送到网线上；

接收网络包：

在Linux2.6版本之后引入了NAPI机制（中断和轮询混合的方式），相比于之前的频繁中断，性能提高了不少；

网卡接收到网络包，发起硬中断；之后执行网卡硬件中断处理函数；
中断处理函数将网络包处理到网卡的Ring Buffer缓冲区，然后暂时屏蔽中断；
唤醒软中断轮询处理数据（可能一次性处理多个网络包），直到Ring Buffer缓冲区没有新数据时才恢复中断；
软中断将Ring Buffer中的数据拷贝到内核缓冲区中；
内核缓冲区中取出数据作为一个网络包交给网络协议栈逐层向上解包；
网络接口层：通过帧校验序列FCS检验数据包的合法性，然后找到上层IP协议类型（IPv4，IPv6），去除帧头帧尾，将数据包交给对应的IP协议栈；
网络层：去除IP报头，然后判断传输层使用的协议，将报文交给对应的传输层协议栈；
传输层：去除TCP头或者UDP头，根据四元组（源IP，源端口，目标IP，目标端口）找到目标IP：目标端口上运行的Socket套接字，将数据拷贝到对应Socket接收缓冲区；
应用层程序使用系统调用从内核的Socket缓冲区拷贝数据到应用程序的缓冲区；

OSI七层模型每一层的详细解释是什么？

从下到上：

层	传输单位	介绍	常见协议
物理层	比特	物理传输媒介的传输，比如电缆、光纤和无线信号	串口通信协议
数据链路层	帧	建立逻辑连接、进行硬件地址寻址、差错校验等功能	PPP点对点协议，MAC介质访问控制协议
网络层	数据报（数据包）	负责数据的路由和转发	ICMP、IP、ARP
传输层	数据段	提供端到端的数据传输服务	TCP、UDP
会话层	会话数据	建立、管理、终止应用程序之间的会话连接	RPC远程过程调用协议
表示层	数据	数据的格式转换、加密、解密（比如将二进制数据转换为视频、图片等）	SSL/TSL协议
应用层	报文	为应用程序提供网络服务	FTP、SMTP、HTTP、DNS

TCP/IP四层网络模型每一层的详细解释是什么？

层	功能	常见协议	对应OSI模型的层次
应用层	提供直接与用户应用程序交互的接口	SMTP、HTTP、FTP等	应用层、表示层、会话层
传输层	负责端到端的数据传输，提供可靠的、无连接的数据传输服务	TCP、UDP	传输层
网络层	负责数据包的路由和转发	IP	网络层
网络接口层	负责物理传输媒介的传输，并提供错误检测和纠正功能，实现MAC寻址、差错检测、以及通过网卡传输网络帧等	ARP	数据链路层、物理层

什么叫端到端？其中端是什么意思？端到端指的是数据从一个端点系统通过网络传输到另一个端点系统的整个过程；端指的是网络通信的起始点或者目的点，比如一个主机就可以是一个端；（也可以立即为端口到端口，即一个主机中端口到另一个主机端口的通信）

TCP/IP模型的数据封装过程：

注意网络接口层，帧头包含MAC地址等信息，帧尾包含FCS校验码；

OSI七层模型和TCP/IP四层模型的异同是什么？

TCP/IP模型更加简洁，在实际的应用生产中使用更多；

五层网络体系结构

结合了OSI七层模型和TCP/IP四层模型提出了五层网络体系结构：

应用层：直接为用户的应用进程提供服务；
传输层：TCP、UDP协议实现两个主机中两个进程的通信；提供端到端的数据传输服务；
网络层：负责数据的路由和转发；
数据链路层：数据帧的传输，并提供错误检测和纠正（FCS校验码），负责数据的帧同步、地址寻址（MAC地址），流量控制；
物理层：光纤、电缆、无线信号的传输的具体方式，比如数据位的形式、电压级别、传输速率等；

FCS校验是什么？在哪一层发生？

在OSI七层模型中的数据链路层，TCP/IP模型的网络接口层发生；

FCS校验是数据帧传输过程中用于检测传输错误的一种校验方式，一般使用CRC循环冗余校验算法来计算；

HTTP请求报文的基本格式是什么？

HTTP请求报文的主体由3个部分构成，分别是请求行、请求头、请求体；

请求行：

包括请求方法、URL、HTTP版本号；
例如POST /user.html HTTP/1.1，表示使用POST请求方法，资源位于根目录下user.html，使用HTTP 1.1协议；

请求头：

包含请求的附加信息，用简单的键值对实现（key-value）；
形式：请求头部字段 : 具体的值；
常见的请求头字段：
- Host：指定服务器的主机号和端口；
- User-Agent：标识客户端的用户代理（浏览器或其他工具）；
- Accept：指定客户端可以接收的响应的MIME类型；
- Content-Type：指定请求主体的MIME类型；
- Authorization：用于身份验证；

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8
Content-Type: application/json
Authorization: Bearer <token>

空行：请求头和请求体之间有一行空行，用于分隔请求头和请求体；

请求体：如果是Get方法，则没有请求头，如果是Post方法，则有请求体，所以请求体不是必须的；（比如Post方法时，登录的用户名和密码在请求体中保存然后传输）

具体的例子：

GET /example/index.html HTTP/1.1 // 请求行
Host: example.com // 各种请求头
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8

// GET方法可以没有请求体

HTTP响应报文的基本格式是什么？

主要包括三个部分：状态行、响应头、响应体；

状态行：包括三个部分，HTTP版本、状态码、状态消息（对状态码的简要描述）；比如HTTP/1.1 200 OK；

响应头：以键值对的形式提供额外信息，类似于请求头；

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Server: Apache/2.4.38 (Unix)
Set-Cookie: session_id=abcd1234; Expires=Wed, 11 Aug 2023 00:00:00 GMT

空行：位于响应头和响应体之间，用于分隔响应头和响应体；

响应体：服务器返回客户端的实际数据（比如客户端请求了Index.html，则服务器返回Index.html的具体内容）

具体的例子：

HTTP/1.1 200 OK // 响应行
Content-Type: text/html; charset=UTF-8 // 各种响应头
Content-Length: 1234
Server: Apache/2.4.38 (Unix)
Set-Cookie: session_id=abcd1234; Expires=Wed, 11 Aug 2023 00:00:00 GMT

<!DOCTYPE html> // 响应体，响应体和响应头之间有一个空行
<html>
	<head>
		<title>Example Page</title>
	</head>
<body>
	<h1>Hello, World!</h1>
</body>
</html>

URL和URI的区别？

URI：统一资源标识符，用于标识互联网上的资源，无论资源是什么类型；

URL：统一资源定位符，URL是URI的一种特殊形式，它不仅标识资源，而且标识资源的所在位置；

URL的构成：

协议：比如HTTP、HTTPS、FTP等；
域名或IP地址；
端口号；
路径：资源的具体路径；
查询参数：GET方法的参数在URL中；
片段标识：标识资源中的特定片段或者位置；

https://www.example.com:8080/path/resource?param=value#section ：使用了https协议，域名为www.example.com，使用8080端口，资源位置为根目录下的path/resource，参数param的值为value，片段标识为section；

HTTP的常见响应码及其含义是什么？

HTTP有5大类状态码：

状态码	具体含义	常见状态码
`1xx`	提示信息，表示目前协议还是中间状态，要进一步操作
`2xx`	成功，报文已经收到并被正确处理	200、204、206
`3xx`	重定向，资源位置发送变化，需要重新发送请求	301、302、304
`4xx`	客户端错误，请求报文有错误，服务器无法处理	400、403、404
`5xx`	服务器错误，服务器在处理请求时内部发送错误	500、501、502、503

200 OK：客户端请求成功，服务器返回了有效资源；

301：永久重定向，表示请求的资源已经永久被移动到了新的位置；

400：请求报文语法有错误，服务器无法识别；

401：请求需要认证（比如登录）；

403：服务器理解请求的资源，但是请求的对应资源被禁止访问；（比如对应资源为不可读状态）

404：服务器无法找到对应资源；

503：服务器正忙（可能是负载过重）；

500：服务器内部错误；

什么是TCP粘包问题？如何解决TCP粘包问题？

为什么会发生粘包？

TCP是基于流的传输层协议（和基于数据报的传输层协议UDP对比）
- 基于流的传输层协议就像“水流一样”，按照字节从发送端流动到接收端；
- TCP在发送数据之前，会将数据放在系统的内存缓冲区中，如果每一次缓冲区没满就发送，则会造成很大的性能损耗（因为发送的次数越多，重复的信息被发送的次数越多，还会有各种校验和确认），所以每一次都会等待缓冲区满了之后才会发送；
- 如果有很多较小的数据报，比如缓冲区大小为20K，数据报都是2K，缓冲区就可以放下10条数据报之后再发送，而且这些数据报并不一定属于一个应用；
- 接收方收到消息后，10条数据报粘在一起，这就是粘包；（TCP只有流的概念，没有包的概念，所以原来的包粘在一起变成了流）
- 而UDP协议基于数据报，10条2K的消息至少发送10次，不会发生粘包；
TCP是长连接的协议（和短连接的HTTP协议对比）：
- TCP协议是长连接协议，发送完数据之后并不会关闭连接；多个消息可能再同一条连接上发送，多个消息可以合并为一个消息发送，导致粘包；
- HTTP是短连接协议，发送完一条数据收到响应后就离开关闭连接；所以每条数据都是独立发送的，不会发生粘包；

TCP粘包是怎么发生的？

粘包问题指的是在数据传输过程中，**发送方将多个消息合并成一个消息一起发送，接收方接收到的数据不是按照发送方发送的消息边界来划分的现象。**这会导致接收方无法准确解析和处理消息，造成数据解析错误。

每一条消息长度相较于缓冲区大小较小，如果每一条消息单独发送，每一次都要校验、确认、重复发送头部信息等，造成性能损耗；所以将多条消息放在缓冲区然后等缓冲区满了一次性发送，此时就会发生粘包；

TCP拆包是怎么发生的？

发送方拆包：传输层有最大传输限制MTU，TCP报文长度超过这个大小要分为多个报文段；如果一个消息过大，则需要拆分为多个报文段来发送；
接收方拆包：接收方收到粘包之后，要拆分出来不同应用的不同数据包；

如何解决TCP粘包问题？

格式化数据：在每一条消息里加入开始符、结束符（注意报文中不能有相同的开始符或结束符）；
发送长度：在每一条消息前加上消息长度后一并发送；

注意TCP协议并不会拆分消息和合并消息，TCP是基于字节流的传输协议，在TCP眼里并不存在“消息的边界”，既然不存在边界，更无从谈起拆分和合并，不管我们在缓冲区里面放了多少条消息，TCP眼里就是将缓冲区的数据流到服务器缓冲区；（拆分和合并是我们眼中的样子，是应用层的样子，绝不是TCP眼中的样子）

TCP不会进行拆分和合并消息，拆分和合并消息是交给应用层来完成的；

GET和POST的区别是什么？从方法、安全性、缓存机制、时间消耗、编码方式等方面讲述。

方法比较：

GET方法用于获取资源，不会对服务器造成影响；POST方法用于客户端向服务器提交数据（提交表单），可能会改变服务器中某些资源；
GET方法一般没有请求体，POST方法一般有请求体；
GET方法如果要进行参数传递要直接在URL中传递，不能大于2KB，只能使用ASCII码；POST要进行参数传递会在请求体中传递，没有大小限制，没有数据格式限制；

安全性（安全即不会破坏服务器资源，幂等即多次操作结果相同）：

GET方法是安全和幂等的，即使用前和使用后并不会破坏服务器资源，是只读操作，每次结果相同；
POST方法不是安全和幂等的，会修改服务器上的资源，并且多次提交资源会创建多个资源；

缓存机制：

GET会被浏览器自动缓存，如果下一次GET时，会直接返回缓存内容；POST不会被自动缓存；
GET请求参数会被完整保存在浏览器的历史记录中（即URL会被完整保存），POST中参数不会；
GET产生的URL可以被完整保存在书签中，POST不可以；
GET在浏览器回退时无害，POST会再次提交表单；

时间消耗：

GET只产生一个TCP数据包，浏览器会直接将Header和Data一起发送，服务器返回200 OK；
POST产生两个TCP数据包，浏览器先发送Header，服务器响应100 continue，浏览器再次发送Data，服务器响应200 OK；

编码方式：

GET方法只能使用URL编码；
POST方法支持多种编码方式；

SSL/TLS是什么？

SSL：安全套接字；

TLS：安全传输层协议；

HTTPS：基于SSL/TLS的安全版本的HTTP协议；

SSL/TLS保证安全传输的方法：

加密：使用对称加密和非对称加密实现传输数据的加密；
身份验证：使用数字证书验证通信双方的身份；
数据完整性：通过消息摘要算法（哈希），防止数据在传输过程中被篡改；

本地HOST文件是什么？

本地的HOST文件是一个没有扩展名的文本文件，用于将特定主机名映射到对应的 IP 地址。它通常用于在没有DNS服务器或在DNS解析之前本地解析主机名和 IP 地址的过程中。

例如：

127.0.0.1       localhost
192.168.1.100   myserver

在DNS解析中，先查浏览器缓存，之后就会查HOST缓存，如果没有才会向本地的DNS服务器发送查询请求；

TCP和UDP比较差异?

连接：TCP面向连接，UDP无连接；TCP需要三次握手建立连接以及四次挥手断开连接，UDP直接传输数据包；
服务形式：TCP是一对一的通信，UDP是一对一、一对多、多对多的通信；
可靠性：TCP保证数据可靠交付，有确认应答机制，有重传机制；UDP只是尽可能交付，没有重传机制，不保证可靠性；
流量控制和拥塞控制：TCP有流量控制和拥塞控制，UDP没有；UDP数据发送速率不受限制；
首部开销：TCP首部大小通常20字节，UDP为8字节，TCP首部开销大；
传输方式：TCP是基于字节流的传输，保证传输顺序和可靠性；UDP是基于数据包的传输，不保证传输顺序，接收方可能收到乱序的数据包；
分片方式：TCP报文在大于MSS时会在TCP层就进行分片，UDP报文在大于MTU时在IP层分片而不是UDP层；在IP层分片如果分片丢失可能导致整个IP报文都丢失；
适用场景：TCP适用于对可靠性有要求的场景，UDP适用于对实时性有要求的场景；

TCP如何实现它的可靠性？

校验和、序列号、确认重答、超时重传、连接管理、流量控制、拥塞控制；

序列号和确认重答：TCP每发送一个数据包就会给它分配一个序列号，用确认应答ACK机制来追踪数据的传输和接收；

重传机制：如果在RTO时间内没有收到发出消息的ACK，则重新发送（超时重传）；或者连续三次收到相同的ACK消息，则重传（快速重传）；

流量控制：适用滑动窗口机制控制数据的发送速率；

拥塞控制：用拥塞窗口控制数据的发送速率，以适应网络状况；

如何让UDP也实现可靠性传输？

UDP延迟低，适用于实时系统；有时候我们难以忍受TCP的延迟，所以只能选择UDP，可UDP又是不可靠的，所以我们必须在UDP的上层提供各种机制保证数据传输的可靠性；

在应用层实现超时重传机制和确认序列号：

在UDP数据包前加上一个首部，包含确认序列号和时间戳；
根据时间戳计算出RTT，然后设置合适的RTO，通过“等-停”的方式发送数据报（即发送完之后停止发送，等待对端的确认之后才继续发送）
对端可以根据确认序列号进行回应（将原来首部的序列号时间戳加到回复报文的首部），并对收到的数据进行排序，实现数据传输的有序性；

已经实现的可靠UDP：

RUDP可靠数据报传输协议；
RTP实时传输协议；
UDT面向连接的双向互联网传输协议；

Keep-Alive是什么？在Http中和TCP中Keep-Alive有什么异同？

Keep-Alive代表长连接；在HTTP/0.9中使用了短连接，每一次发送消息并接收到响应之后就会断开连接；而在HTTP/1.0中，将之前的短连接变成了可选的长连接，即只要在请求头中配置Connection : Keep-Alive即代表开启了长连接；在后续的HTTP/1.1中，默认开启了长连接；

在启用了Keep-Alive的情况下，客户端和服务器在完成了一个HTTP请求和响应之后，并不立刻关闭连接，而是继续保持连接为打开状态，双方就可以继续通信，无需重新建立连接，减少了连接的建立和关闭的开销；

Keep-Alive的优缺点：

优点：
- 减少频繁建立连接和关闭连接，提高了性能和效率；
- 客户端可以一次性发送多个请求，服务端可以并行处理这些请求；
- 多个请求可以共享同一个连接的头部信息（比如用户代理、Cookie等），减少了头部信息的重复传输；
  - 比如一个GET请求和一个POST请求的请求头都有HOST请求头规定了服务器的主机地址，我们就可以只发送一次HOST字段；
缺点：
- 长时间保持连接状态可能会占用服务器资源；（一般会设置Keep-Alive的超时时间，如果一段时间内不发送消息或者发送消息的次数很少，则相比于保持连接来说关闭更具效率）

TCP中的Keep-Alive（TCP的保活机制）：

TCP本来就是长久连接，可是如果通信双方长时间没有发送数据报，没有实际的数据传输，则保持长连接会大量浪费资源；如果对端关机了，并且发送的RST报文丢包了，则无法通知对方关闭连接，对方一直傻傻的等着，及其浪费资源；所以TCP的KeepAlive就是为了避免这一情况，通过发送特定的探测数据报来维护连接的稳定性；

过程：

启动Keep-Alive：TCP在建立连接时，通过设置SO_KEEPALIVE选项来启动Keep-Alive机制；
定时发送探测报文：操作系统内部有一个定时任务做倒计时，如果超时，则会触发发送一个空的探测报文到对端，用来判断对端是否存活；
等待对端响应：如果对端收到报文，则返回一个空的ACK数据报，告诉发送端还活着；如果对端程序崩溃，则返回一个RST报文强制关闭连接；如果报文不可达，则重新发送；
超时关闭连接：如果发送了很多次Keep-Alive（一般是3次以上）都没有收到响应，则判断连接已经断开，发送端关闭这个连接，回收相应资源；

Keep-Alive的超时时间和探测频率要根据实际需要设置，如果超时时间过长可能导致连接维护时间过长，超时时间过短，可能导致频繁发送探测报文；

通过Keep-Alive机制，让TCP长时间的空闲连接持续保持活力；（让连接基本活跃）

HTTP的Keep-Alive和TCP的Keep-Alive：

是两个东西，实现的层次不同；

HTTP的Keep-Alive是应用层实现的；称为HTTP长连接，如果不使用Keep-Alive，每一次发送资源的过程是：建立TCP（三次握手）——>请求资源——>响应资源——>释放连接（四次挥手），使用之后的过程：建立TCP（三次握手）——>请求资源——>响应资源——>继续请求资源——>继续响应资源——>…——>释放连接（四次挥手）；
TCP的Keep-Alive是TCP层（内核态）实现的，是操作系统和网络协议栈级别实现的，称为TCP的保活机制（不是TCP的长连接机制，TCP即使没有Keep-Alive也是长连接的），是一种用于在TCP连接上检测空闲连接状态的机制；

CDN是什么？

我们要向目标服务器获取资源，如果目标服务器很远怎么办？如果自己有缓存当然可以解决，可是一台主机的缓存容量有限，而且大部分时间我们访问的目标服务器都会据我们很远。

CDN全称为内容分发网络，将内容存储在分布式的服务器上，使用户可以在较近的服务器上获取到所需的资源，从而减少数据传输的时间和距离，提高传输效率；（就是在就近服务器缓存所求的资源，而不只是在本地缓存，本地毕竟缓存的空间小，不如服务器）

工作流程：

用户输入URL申请资源之后，首先会进行域名解析；如果网站开启了CDN服务，则DNS解析会返回距离用户最近的CDN节点的IP地址（而不是原始的目标服务器的IP地址）；
用户的请求会发送到最近的CDN节点服务器，CDN根据服务器的负载情况将请求转发到合适的服务器上；（CDN可以实现动态的负载均衡）
CDN节点检查是否缓存了资源，如果缓存则直接返回，如果未缓存，则向目标服务器获取资源，然后将资源缓存，最后才响应请求；

CDN如何实现提高传输效率的？

就近访问：之前必须到远端的目标服务器获取资源，现在只用到就近的CDN节点服务器获取缓存的资源；
内容缓存：CDN节点会缓存静态资源，当用户请求时不用到目标服务器获取，只用返回缓存；
前置缓存：CDN节点可以有选择地将热门内容缓存在节点中（热门内容不局限于某一个主机，而是很多主机都关心地内容，如果是主机缓存，只关心本主机地热门内容，局限性很大；即使主机之前没有访问过，也可能获取到缓存，只要区域内主机访问过多次即可）
智能负载均衡：CDN节点可以根据服务器的负载，动态地将主机的请求分发到合适的服务器上；
压缩技术：CDN使用压缩技术对内容解析压缩传输；
并行下载：CDN支持多路复用，用户可以在一个连接上同时下载多个资源（即并行获取响应）

Cookie是什么？Session是什么？区别是什么？

如果我们登录了一个网站，然后再关闭之后过了一段时间后重新访问，我们可以发现我们还是登录状态，不需要重新输入用户名密码来登录，这就是因为Cookie在起作用；

如果是购物网站，我们打开购物车，发现之前放入购物车的东西还在，这就是因为服务器为我们创建了一个专属的会话存储空间，而服务器要访问这个专属会话存储空间就要用Session；

Cookie工作原理：

客户端（浏览器）第一次发送请求到服务器；
服务器通过HTTP响应的头部信息中的Set-Cookie来创建一个Cookie。这个请求头指定了Cookie的名称、值和其他参数（过期时间、域名、路径等）；
浏览器收到包含Cookie的响应报文后，会将Cookie保存在本地计算机上；
当用户再次访问同一个网站时，浏览器就会将和该域名相关的Cookie信息包括在HTTP的请求的请求头中；
服务器收到包含Cookie的HTTP请求之后，就可以读取Cookie的值，然后根据其中的值来判断用户的状态、偏好等，并针对用户做出响应；
服务器可以发送新的Set-Cookie来更新Cookie；
Cookie可以设置过期时间，可以是会话级（关闭浏览器后Cookie就失效），也可以是持久性的（到达一定时间后Cookie才失效）。

Session的工作原理：

用户第一次访问网站，服务器为该用户创建一个Session ID（唯一会话标识符），该会话符可以以Cookie的形式保存在用户的浏览器中；
每个Session ID对应服务器上一个独立的会话存储空间，该存储空间可以保存用户在会话期间的状态的数据；
当服务器和用户产生交互时，服务器可以通过Session ID来访问对应的会话存储空间，可以将交互产生的数据放在该空间内；
过期删除：如果一段时间内服务器和浏览器没有会话产生，会自动清空会话存储空间的内容；
手动删除：用户可以通过退出登录等方式来终止会话，会话终止之后服务器会删除和对话相关的信息，即清空会话存储空间；

Cookie和Session的区别：

存储位置：Cookie存储在用户的浏览器中，Session存储在服务器中；
数据容量：Cookie一般很小，Session一般很大；
安全性：Cookie没有Session安全，因为Cookie可以被用户访问和修改；
传输方式：Cookie会在每次浏览器发送请求时放在请求头，而Session ID一般通过Cookie或URL的参数进行传递；

什么是SSO？和普通的登录认证机制有什么不同？

普通的登录认证机制：

用户发送POST请求报文，请求报文中的请求体中包含登录的用户名和密码；
服务器收到POST请求报文，然后再数据库中比对用户名和密码，如果登录成功，则为用户创建一个Session ID，通过Session ID将用户登录信息写入Session；
服务器为用户生成一个Cookie（其中包含Session ID），将Cookie放在响应报文的Set-Cookie请求头字段，然后返回响应报文给用户；
用户的浏览器将响应报文中的Cookie提取出来，缓存到浏览器中；
用户再次申请访问时，再请求报文的Set-Cookie字段中加入缓存的Cookie的信息；
服务器根据Cookie信息找到Session ID，然后根据Session ID访问服务器为用户创建的会话存储空间，通过Session来看用户是否已经登录已经其他会话信息；

缺点：如果在操作不同系统时，可能要多次重复登录；比如我已经登录了QQ，可是还要重复登录QQ邮箱；

单点登录SSO（Single sign-on）：一次登录，多次访问；（用户只要一次登录，就能无缝地访问多个应用）

SSO的实现过程：

用户发起登录请求：用户输入用户名和密码进行登录；
应用程序A收到用户的登录请求报文（POST报文），应用程序A发起SSO认证请求到身份提供者IdP，向IdP传递用户凭证（用户名和密码）以及应用程序A的标识符；
身份提供者IdP验证用户凭证，如果验证成功，会向应用程序A发送一个特殊的令牌（一般是加密的），令牌包含用户标识信息、过期时间等；
应用程序A收到IdP发送的令牌，登录成功；
应用程序A访问其他应用程序，比如应用程序B也需要登录；
应用程序A将令牌发送到应用程序B，应用程序B发起SSO认证请求到IdP中，发送认证请求时附上令牌；
身份提供者IdP验证令牌信息的有效性和正确性，然后授权用户访问应用程序B；
应用程序B就实现了没有输用户名和密码就可以登录；

提供一个独立于服务器和用户的身份提供者IsP来实现登录时用户凭证的验证过程和具体的应用程序解耦合；IsP会根据用户凭证生成令牌，之后用户访问和应用程序A相关的应用程序时，都由应用程序A发送令牌告诉其他应用程序用户的身份，而不是用户自己告诉应用程序身份；

SSO的优点：

降低密码重用风险（多次登录会在应用程序之间重复使用相同的密码，增加了密码泄露的风险）
分别用户的体验；
简化应用开发：将登录和认证交给SSO系统，减少了在每个应用中独立实现登录和认证的逻辑；

例子：通过第三方身份提供者登录的SSO机制；比如某个简单的网站需要实现登录功能，如果网站自己管理登录注册，需要复杂的业务逻辑和校验逻辑，并且用户需要为该网站想一个新的用户名和密码，如果直接使用QQ登录或微信登录就简单很多了；在这里，QQ和微信就扮演了IsP的角色，网站将用户的用户凭证发送到QQ或微信，QQ或微信验证凭证然后返回一个令牌，用户不需要单独注册一个账号供这个网站使用，使得用户可以快速、安全的登录。同时，降低了网站本身的管理账号的负担；甚至账号密码的加密传输也可以由IsP提供；

（危险！如果某个网站使用QQ登录，但是要先输入账号密码，然后网站转发账号密码信息到QQ，获得QQ的令牌，最终确实是完成了QQ的登录，但是QQ的账号和密码也会泄露，而用户可能因为QQ登录成功而放松警惕，没有及时修改密码）

HTTP的优化方案你知道几种？

TCP复用：通过HTTP的Keep-Alive实现持久连接，复用已经建立的TCP连接，避免了每次HTTP请求都要重新建立连接；

HTTP复用：支持在单个TCP连接上复用多个HTTP请求和响应，减少延迟和提高吞吐量；

内容缓存：通过设置缓存，让获取资源时不用必须和服务器通信，而从缓存获取静态资源；

压缩：对报文进行压缩后传输，比如HPACK算法，静态编码表、动态编码表、哈夫曼算法压缩字符串等；

SSL加速：通过硬件加速或高效的加密套件进行优化SSL/TLS加密；

TCP缓冲：调整TCP缓冲区大小，即选择合适的窗口进行发送，避免无谓的等待和内存浪费；

HTTPS的三次握手过程？

包括：对称加密、非对称加密、数字证书；

三次握手过程：（用三个随机数生成对称密钥）

客户端生成一个随机数，并告知服务器自己支持的加密算法；服务器收到随机数，并确认自己是否支持客户端的加密算法；
服务器发送数字证书到客户端，并发送一个服务端随机数，数字证书中包含非对称加密中服务器端的公钥；客户端收到数字证书并校验，校验通过后用数字证书中的公钥加密一个新的随机数；
客户端将公钥加密后的随机数发送到服务器，服务器用自己的私钥解密，获取到第三个随机数；此时，三个随机数双方都已经知道了，根据这三个随机数生成Session Key，作为通信的对称密钥；

https的ssl连接过程

SSL握手是在生成对称密钥，建立TCP连接之后（生成对称密钥的过程顺便也建立了TCP连接）；

客户端发起SSL连接请求：
- 客户端向服务器发起HTTPS连接请求，服务器会返回自己的SSL证书，其中包含公钥等信息。
客户端验证服务器证书：
- 客户端接收服务器的SSL证书后，会验证证书的有效性，包括验证证书的颁发机构是否受信任、证书是否过期、是否匹配等。如果验证通过，客户端将继续SSL握手过程。
生成对称密钥：
- 在SSL握手阶段，客户端和服务器之间会通过协商过程生成对称密钥，用于加密和解密通信过程中的数据。
加密通信：
- 一旦对称密钥生成，客户端和服务器之间的通信将采用对称加密算法进行加密和解密，保证传输数据的安全性。
SSL握手：（3次握手）
- 通过SSL握手过程，客户端和服务器会交换用于加密通信的参数，并验证彼此身份。握手过程包括以下步骤：
  - 客户端发送ClientHello报文：包含支持的SSL/TLS版本、加密算法等信息。
  - 服务器返回ServerHello报文：确认协商的SSL/TLS版本、选择加密算法等。
  - 服务器发送证书报文：将服务器的SSL证书发送给客户端。
  - 客户端验证证书：客户端验证服务器证书的有效性。
  - 客户端发送Finished报文：用于验证握手过程的完整性。
  - 服务器发送Finished报文：同样用于验证握手过程的完整性。
建立安全传输通道：
- 一旦SSL握手成功完成，客户端和服务器之间就建立了安全传输通道，可以开始加密通信。
传输数据：
- 客户端和服务器之间的HTTP通信会通过SSL传输数据，数据在传输过程中受到加密保护，可以有效防止中间人攻击和窃听等安全问题。