目录
1.对网络协议的分层？
2.TCP/IP和UDP之间的区别？
3.建立TCP连接的三次握手？
4.断开TCP连接的四次挥手？
5.TCP协议如何保证可靠性传输？
6.什么是TCP的拥塞控制？
7.什么是HTTP协议？
8.HTTP常用的状态码及其含义？
9.HTTP常用的请求方式用途？
10.HTTP和HTTPS的区别？
11.HTTPS工作原理？
12.HTTPS的传输过程？
13.浏览器输入url到显示主页过程？
14.HTTP版本差异对比？
15.HTTP请求转发和重定向的区别？
16.Cookie和Session区别？
17.什么是Token，Token和Session的区别是什么？
1.对网络协议的分层？
网络协议分层有三种方式，分别是：七层协议、五层协议、TCP/IP四层协议
- ISO七层模型是国际标准化组织制定的一个用于计算机或通信系统间互联的标准体系：
- 应用层：网络服务与最终用户的一个接口，常见的协议有：HTTP FTP SMTP SNMP DNS.
- 表示层：数据的表示、安全、压缩。，确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。
- 会话层：建立、管理、终止会话,对应主机进程，指本地主机与远程主机正在进行的会话.
- 传输层：定义传输数据的协议端口号，以及流控和差错校验,协议有TCP UDP.
- 网络层：进行逻辑地址寻址，实现不同网络之间的路径选择,协议有ICMP IGMP IP等.
- 数据链路层：在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路。
- 物理层：建立、维护、断开物理连接。五层协议体系结构各层与ISO七层一致，参考七层。
- TCP/IP四层协议结构
- 应用层：对应于OSI参考模型的（应用层、表示层、会话层）。
- 传输层: 对应OSI的传输层，为应用层实体提供端到端的通信功能，保证了数据包的顺序传送及数据的完整性。
- 网际层：对应于OSI参考模型的网络层，主要解决主机到主机的通信问题。
- 网络接口层：与OSI参考模型的数据链路层、物理层对应。
Ps：五层协议各层作用可参考ISO七层模型，不做赘述
2.TCP/IP和UDP之间的区别？
TCP/IP协议：即传输控制协议，是面向连接的协议，发送数据前需要先建立连接，是可靠的数据传输协议。也就是说，通过TCP协议进行的数据传输没有数据丢失、不会乱序、不会重复。
UDP协议：是TCP/IP协议簇中的一种，是无连接的协议，发送数据前无需建立连接，是非可靠的传输协议。
两者之间的区别：
- UDP无连接协议，是不可靠传输协议；TCP面向连接，是可靠的数据传输协议
- UDP传输的运输协议数据单元是UDP报文或者用户数据报文；TCP传送的运输协议数据单元是TCP报文
- UDP支持单播、多播、广播；TCP协议只支持点对点传输数据
- UDP简单，适用很多应用，如多媒体服务；TCP复杂，用于很多应用，如万维网、电子邮件、文件传输等
- UDP传输数据无序；TCP传输数据有序
- UDP传输耗时短；TCP传输耗时更长一点。
3.建立TCP连接的三次握手？
TCP协议是可靠数据传输协议，传输数据前建立连接的过程称之为三次握手。过程：客户端向服务器发送SYN -> 服务端接收到后向客户端发送SYN和ACK -> 客户端受到后回执服务端ACK。
- 第一次握手：主机A的TCP向主机B发出连接请求报文段，其首部中的同步位SYN = 1，并选择序号seq = x；
- 第二次握手：主机B的TCP 收到连接请求报文段后，如同意则发回确认。主机B在确认报文段中应使SYN = 1，使ACK = 1，其确认号 ack = x + 1，自己选择的序号 seq = y。
- 第三次握手：主机A 收到此报文段后向主机B给出确认，其ACK = 1，确认号ack = y + 1。主机A 的TCP通知上层应用进程，连接已经建立。主机B的TCP收到主机A的确认后，也通知其上层应用进程：TCP 连接已经建立。
Ps：为什么不能两次握手呢？是因为三次握手主要是为了防止已失效的连接请求报文段又传输到服务端，数据就会有问题。
比如场景：客户端A发起连接请求，但因为网络堵塞等原因没有收到B的确认消息，那么A就会重新发起第二次连接请求，连接成功并且数据传输完成后已经断开连接后，第一个连接请求到达B，此时B会误以为A又重新发起一次连接，假设没有第三次握手的情况下，此时B发送确认消息则连接就建立成功了。
4.断开TCP连接的四次挥手？
数据传输完成后需要断开TCP连接，此时断开过程需要进行四次挥手，过程：客户端主动发起关闭向服务端发送消息 -> 服务端接收断开消息后的确认消息发回客户端 -> 服务器端发起断开连接消息 -> 客户端接收到服务端消息后进行确认关闭并发回服务端
- 第一次挥手：主机A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。主机A把连接释放报文段首部的FIN = 1，其序号seq = u，等待 B 的确认（FIN_WAIT_1状态）。
- 第二次挥手：主机B发出确认，发送一个ACK=1，确认 ack= u+1，而这个报文段自己的序号seq = v。TCP 服务器进程通知高层应用进程。从主机A到主机B这个方向的连接就释放了，TCP连接处于CLOSE_WAIT状态。此时主机B若发送数据，主机A仍要接收。
- 第三次挥手：主机B确认已经没有要向主机A发送的数据，将FIN置1，其应用进程就通知TCP释放连接。
- 第四次挥手：主机A收到连接释放报文段后，进入TIME_WAIT状态，必须发出确认。在确认报文段中ACK = 1，确认号ack = w + 1，自己的序号seq = u + 1。主机B收到后，确认ack后，变为CLOSED状态，不再向客户端发送数据。客户端A等待2*MSL（报文段最长寿命）时间后，也进入CLOSED状态。完成四次挥手。
Ps：一些常见的其他明知故问~
- 为什么不能三次挥手呢（lose_wait状态的意义是什么）？
- 答：假设三次挥手，那么服务器在接收到客户端断开连接请求发送确认消息的时候就要一并开始发起断开连接，此时有可能服务端还有数据传输未完成，此时断开会导致数据丢失。
- 如果二次挥手的服务端消息没有成功发送到客户端会怎样？
- 答：客户端会间隔时间重复发送断开连接请求
- 客户端处于time wait代表什么？
- 答：客户端time wait表示收到了服务端的断开连接请求但还没回复服务端，用来重发可能丢失大的ACK报文，如果超过2*MSL服务端会重新发送断开连接请求消息，不断重试。可能问题是：主机A发送的ACK没有成功被B接收，或者发送的报文段已过期。
- 四次挥手中最后为什么客户端要等2*MSL才close？
- 答：其一为了保证A发送的最后一个ACK能到达B，假设ACK丢失的话在这个时间内B会重新发起断开连接请求。其二：为了防止已失效的连接请求报文出现在本次连接中，等2*MSL可以确保本次连接的报文全部消失，避免印象下一次网络连接。
5.TCP协议如何保证可靠性传输？
停止等待：每发完一个分组就停止发送，等待对方确认，在收到确认后再发下一个分组。
超时重传：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
拥塞控制： 当网络拥塞时，可能会造成网络的拥堵，甚至网络瘫痪，TCP会减少数据的发送。
数据包校验：TCP 将保持它首部和数据的检验和，这是一个端到端的检验和。目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
丢弃重复数据：TCP 的接收端会丢弃重复的数据。
6.什么是TCP的拥塞控制？
TCP的拥塞控制是为了防止过多数据注入网络，使网络中的路由器或者链路过载。流量控制是点对点的通信量控制，拥塞控制是全局的网络流量控制，发送双方都有一个拥塞窗口（cwnd）:
- 慢开始：最开始发送方的拥塞窗口为1，每次发送为前一次的2倍增长。当拥塞窗口超过慢开始流量限制，则开始使用拥塞算法；
- 拥塞避免（算法）：当拥塞窗口超过慢开始门限，每隔一个往返时间cwnd+1，在慢开始和拥塞避免中一旦发现网络堵塞则把慢开始门限置为当前的一半，cwnd重新置为1，再次慢开始重新启动。
- 快重传：接收方每收到一个失序的报文段就立即发送重复确认，当发送端收到3个重复确认后立即重传
- 快恢复：当发送方连续收到三个重复确认，就将慢开始门限减半。将当前窗口中设置为慢开始门限，并采用拥塞避免算法。采用快恢复时，慢开始只在建立连接和网络超时时使用。
7.什么是HTTP协议？
http协议是基于TCP/IP协议的一种传输协议，HTTP协议工作于客户端-服务端架构之上，是应用层协议，也叫超文本传输协议。
特点：①简单快速：客户端向服务器发送请求时，只需传送请求方法和路径即可。
②灵活：HTTP允许传输任意类型的数据对象。
③无连接：限制每次连接只处理一个请求。服务器处理完客户请求，并收到客户应答后，即断开连接。
④无状态：协议对于事务处理没有记忆能力。
⑤支持B/S及C/S模式。
8.HTTP常用的状态码及其含义？
按类别状态码总结：
日常开发中常见的状态码：
9.HTTP常用的请求方式用途？
10.HTTP和HTTPS的区别？
- 端口不同：HTTP端口是80，HTTPS端口是443
- 安全性：HTTP是超文本传输协议，信息是明文传输，HTTPS是经过SSL加密数据后传输，更安全
- 是否付费：HTTPS需要拿到CA证书，需付费
- 连接方式：HTTP连接简单，无状态；HTTPS通过SSL加密+HTTP协议构建的可加密传输、身份认证的网络协议，更加安全。
- 传输耗时：HTTPS增加了一层SSL加密，所以延时会增加
11.HTTPS工作原理？
- 首先HTTP请求服务端生成证书，客户端对证书的有效性、合法性、域名是否一致、证书公钥（RSA）进行验证
- 客户端校验证书通过后，根据证书的有效生成随机数，随机数使用RSA加密算法进行加密
- 消息体产生就就对它的摘要进行MD5(或SHA1)算法加密，生成RSA签名
- 发送给服务端，此时只有服务端RSA密钥可以进行解密
- 解密得到随机数在使用AES加密，作为密钥（此时只有客户端和服务端知道）
Ps：一丢丢扩展内容~
加密算法有三类：
- 对称加密（AES加密）基本原理：将明文分成 N 个组，然后使用密钥对各个组进行加密，形成各自的密文，最后把所有的分组密文进行合并，形成最终的密文。 优点：算法公开、计算量小、加密速度快、加密效率高。缺点：双方都使用同样密钥，安全性得不到保证。
- 非对称加密（RSA加密） 基本原理：同时生成两把密钥：私钥和公钥，私钥隐秘保存，公钥可以下发给信任客户端。私钥加密，持有私钥或公钥才可以解密； 公钥加密，持有私钥才可解密。 优点：安全，难以破解 。缺点：算法比较耗时。
- 不可逆加密（如 MD5，SHA）基本原理：加密过程中不需要使用密钥，输入明文后由系统直接经过加密算法处理成密文，这种加密后的数据是无法被解密的，无法根据密文推算出明文。
12.HTTPS的传输过程？
- 建立TCP连接（HTTP） ：将HTTP请求转换为HTTPS请求，转到HTTPS网站
- 建立新的TCP连接(HTTPS) ：因为HTTP与HTTPS的端口不同。HTTP使用80端口，HTTPS使用443端口
- 完成一系列的协商工作 ：完成加密套件的协商和证书的身份确认，这次交互客户端和服务端会协商出相同的密钥交换算法、对称加密算法、内容一致性校验算法、证书签名算法等等。浏览器获取到证书之后，也要验证证书的有效性，是否过期是否撤销
- 浏览器获取CA域名 ：如果没有CA域名的缓存，还需要进行DNS解析
- 再次建立新的TCP连接（CA域名）
- 发送OCSP请求 ：OCSP全称是Online Certificate Status Protocol，在线证书状态协议，顾名思义用来获取证书状态的请求，这里的状态包括有效、过期、未知。并且可以宽限一段客户端访问证书的时间
- 进行密钥协商
13.浏览器输入url到显示主页过程？
- URL解析：当用户在浏览器的地址栏中输入URL时，浏览器会首先对该URL进行解析。解析URL包括识别协议（例如HTTP、HTTPS）、主机名（例如www.example.com）、路径（例如/index.html）等。
- DNS解析：浏览器将解析出的主机名发送到DNS（域名系统）服务器，以获取该主机名对应的IP地址。如果该主机名已经被缓存，则直接从缓存中获取IP地址；否则，将向DNS服务器发送DNS查询请求。
- 建立TCP连接：浏览器使用HTTP或HTTPS协议与获取的IP地址上的服务器建立TCP连接。对于HTTPS协议，还会进行SSL握手过程，确保通信安全性。
- 发送HTTP请求：一旦TCP连接建立，浏览器会向服务器发送HTTP请求，请求页面或资源。请求头部可能包括信息如请求的方法（GET、POST等）、所需的页面或资源、浏览器的相关信息等。
- 服务器处理请求：服务器接收到浏览器发送的HTTP请求后，会根据请求的内容和服务器的配置进行相应的处理。处理过程可能包括读取文件、执行脚本、访问数据库等操作。
- 服务器返回响应：服务器处理完请求后，会生成相应的HTTP响应，包括响应头和响应主体。响应头包括状态码（如200表示成功，404表示未找到页面等）、服务器信息、内容类型等。响应主体则包含请求的页面内容或资源的数据。
- 浏览器接收响应：浏览器接收到服务器返回的HTTP响应后，开始解析响应内容。如果是HTML页面，浏览器会解析HTML文档，并同时获取并解析页面中引用的外部资源，如CSS样式表、JavaScript脚本、图像等。
- 渲染页面：浏览器根据HTML文档和相关资源，将页面内容呈现在用户界面上。页面的呈现包括解析HTML结构、应用CSS样式、执行JavaScript代码等步骤。
- 显示页面：最终，浏览器将渲染好的页面显示给用户。用户可以与页面进行交互，如点击链接、填写表单等。
扩展解释：
URL解析过程：
- 地址解析：浏览器会根据你的输入来判断该输入是一条合法的URL，还是需要被搜索的关键词。并且根据你输入的内容进行自动完成、字符编码等操作。
- 其他操作：目前大部分浏览器都会强制客户端使用HTTPS协议以保证信息传输的安全性。同时还会进行一些额外的操作，比如安全检查、访问限制等。
- 缓存检查：浏览器会先检测是否缓存了目标URL的页面，如果有且缓存未过期，则直接展示缓存页面，无需再向服务器进行请求
DNS解析：是寻找所需要的资源的IP地址的过程。因为互联网中每一台连网的机器都有唯一IP作为标识，但是它是一串数字，记忆太过困难。所以就需要将网址和IP地址进行转换，也就是DNS解析。
- 查询缓存 ：我们的浏览器、操作系统、路由器都会缓存一些URL对应的IP地址，统称为DNS高速缓存。这是为了加快DNS解析速度，使得不必每次都到根域名服务器中去查询。
- 递归解析 ：输入www.baidu.com网址后，首先在高速缓存中查找，没找到去根域名服务器查找，没有再去com顶级域名服务器查找，依次类推，直到找到IP地址，然后把它记录在本地告诉缓存中，供下次使用。 大致过程就是.-> .com ->baidu.com. -> www.baidu.com. 其中.代表根域名服务器。
- DNS负载均衡 ：访问baidu.com的时候，每次响应的可能并非是同一个服务器（IP地址不同），一般大公司都有成百上千台服务器来支撑访问，DNS可以返回一个合适的机器的IP给用户，例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是DNS负载均衡。
14.HTTP版本差异对比？
| HTTP1.0 | HTTP1.1 | HTTP2.0 |
|---|---|---|
|
|
|
15.HTTP请求转发和重定向的区别？
请求转发：
- 浏览器只发出一次请求，收到一次响应
- 请求的数据可以直接被被盗到转发请求中
- 浏览器URL地址就是用户提交时的地址保持不变
- 只能跳转到当前应用的资源中
请求重定向：
- 浏览器发出两次请求，两次响应
- 重定向的资源不能直接携带用户请求携带的数据
- 浏览器URL地址显示的是重定向后的新URL，并非客户提交的URL。因此重定向的一个作用是防止表单重复提交（恶意刷新页面，刷新一次提交一次）
- 重定向可以跳转到当前应用中资源，也可以跳转到其他应用的资源去
16.Cookie和Session区别？
HTTP协议本身是无法判断用户身份,所以需要Cookie或者Session：
Cookie：是由Web服务器保存在用户浏览器上的文件（key-value格式），可以包含用户相关的信息。客户端向服务器发起请求时，会携带服务器端之前创建的Cookie，服务器端通过Cookie中携带的数据区分不同的用户。
Session：是浏览器和服务器会话过程中，服务器会分配的一块储存空间给Session。服务器默认会为客户浏览器的Cookie中设置SessionId，这个SessionId就和Cookie对应，浏览器在向服务器请求过程中传输的Cookie包含SessionId ，服务器根据传输Cookie中的SessionId获取出会话中存储的信息，然后确定会话的身份信息。
两者区别：
- 安全性：Cookie数据存放在客户端上，安全性较差，Session数据放在服务器上，安全性相对更高
- 大小限制：Cookie有大小限制，单个Cookie保存的数据不能超过4K，Session无此限制，理论上只与服务器的内存大小有关
- 服务器资源消耗：Session是保存在服务器端上会存在一段时间才会消失，当访问增多，对服务器性能有影响
- 实现机制：Session的实现常常依赖于Cookie机制，通过Cookie机制回传SessionId
17.什么是Token，Token和Session的区别是什么？
Token是服务端生成的一串字符，以作为客户端请求的令牌。服务端生成Token给客户端后，客户端每次请求只需要携带这个Token，无需每次请求都带上用户名和密码，让服务器一遍一遍对比用户名和密码。
和Session对比：
- Session机制存在服务器压力增大、CSRF跨站伪造请求攻击、扩展性不强等问题
- Session存储于服务器，Token存储于客户端
- Token提供认证和授权功能，作为身份认证，Token比Session安全性好
- Session这种会话存储方式只适用于客户端和服务端运行在同一台服务器上，Token适用于前后端分离
![[linux]sed命令基础入门详解](https://i-blog.csdnimg.cn/direct/eb773c12c6fa44a6b6c814f5924676a6.png)
