计算机网络相关

首先，网络分层，在数据传送过程中会遇到各种各样不同的问题，因此可以对网络进行分层，每一层负责专门的问题

OSI开放系统互联参考模型

应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

TCP/IP协议族

应用层、传输层、网络层、数据链路层、物理层

http协议(超文本传输协议)

http 是客户端和服务端之间进行数据传输的格式规范，是一种明文传输、无状态、无连接，以请求/应答方式运行的应用层协议
无状态：服务器不会记得客户的一些状态，每一次请求都是独立的（->cookie session 添加链接描述）
无连接：http使用了tcp连接，在传输报文之前是不用建立http连接的
明文传输：明文意味着在传输过程中的信息，是可⽅便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接⾁眼查
看，为我们调试⼯作带了极⼤的便利性

http是无状态的，怎样解决去状态的缺陷，cookie、session

http是无状态的，服务器无法从网络连接上得知用户的状态，为了支持客户端与服务器的交互,就有了cookie和session
当服务器第一次收到客户端的请求时，会开辟一个session空间，用来记录客户的一些信息状态，同时生成一个sessionid,并通过发送响应让客户端设置cookie,客户端收到响应后，会在本机设置一个cookie文本文件记录sessionid,等到下一次客户端在请求服务器时，请求头里就会携带上cookie,服务器以此来辨别用户的状态和信息

cookie服务器会给客户端版发一个cookie，客户端浏览器就会把cookie保存起来，当浏览器再次请求的时候就会把cookie一同携带过去，然后服务器通过检查cookie来辨别用户状态(登录时就可以记住他的登录信息，下次访问时不需要再次登录，直接访问即可。)
session：当客户端访问服务器时，服务器会把客户端的一些信息记录在服务器上，这就是session,当客户端再次访问服务器时，只需要在seesion中查找到相应的信息就可以了 （购物车，使用session标记用户的购物车里的信息）
但是cookie、session认证机制有弊端：
服务器的资源占用量大，因为每一个用户都会创建一个session
当客户第一次访问的是服务器1，第二次访问服务器2就没有用户的session信息了
所以使用token认证机制

Token

用户使用用户名密码登录
服务器收到请求，验证用户名和密码
如果验证成功，就发送一个token给客户端
客户端会存储这个token ,客户端每次向服务器请求资源的时候会携带上token
服务端收到请求后就会验证token,验证成功才会返回数据

Sesion和Token的区别

Session是一种记录在服务器的，可以用来记录用户的状态。而Token是一种请求资源时需要的凭证，不会存储会话信息

http1.1和http1.0的区别

1.0在一次请求和响应后就会断开TCP连接，所以每一次请求都要建立连接
1.1新增

• 持续连接：在http2.0里有持续连接，当一次响应后，在一段时间里不会断掉TCP连接
  持续链接方式
• 管道传输
  非流水线：发请求时要等到上一次相应回来之后才能发送新的请求
  流水线方式：发了一次请求之后，可以继续发送请求，不必等上一次的响应
• 控制缓存首部字段：expires->cache-control if modify since & last modified->Etag
• 新增了请求方法 put option

关于http2.0

• 服务器端推送’，它允许服务器端在客户端需要数据前主动将数据发送到客户端缓存中，从而提高性能
• 2进制，在http1.2中，数据可以是文本也可以是二进制，而在http2.0中数据全部为二进制传输，增大数据传输效率
• 压缩请求头，因此请求非常小，请求和响应的 header 只占很小的带宽比例
• 多路复用，客户端和服务器可以在同一时间里发送多个请求或回应，而不用按照顺序发送，避免了队头堵塞
• 数据流，每个请求或响应的所有的数据包就是一个数据流，因为http2的数据包不是按顺序发送的，所以就得给数据包做标记，来区分它是那个数据流

http3.0

http3.0是基于UDP实现的，实现了类似TCP流量控制，多路数据流，可靠性传输的功能

队头堵塞

队头阻塞是由 HTTP 基本的“请求 - 应答”模型所导致的。HTTP
规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象。
队头阻塞的解决方案： （1）并发连接：对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。 （2）域名分片：将域名分出很多二级域名，它们都指向同样的一台服务器，能够并发的长连接数变多，解决了队头阻塞的问题。

GET POST 的区别

（偿还参数）

• 参数长度：因为get请求的参数是拼接在url中的，浏览器对于url有长度要求，所以GET请求发送的数据长度有要求。而POST请求的参数数据都在请求体里，所以没有长度要求
• 缓存区的使用：一般get请求是用来获取数据的，所以浏览器一般会对get请求使用缓存，而post请求是用来提交一些数据的，所以一般不会使用缓存
• 参数类型：post的参数支持更多的数据类型
• 数据包：get请求产生一个数据包，post请求产生两个数据包
  （get请求时，浏览器一般会将请求头和请求体一块发送给服务器，然后服务器返回200（返回数据），而post请求，浏览器会先将请求头发送出去，服务器返回100后继续发送请求体。 这样做在网络环境差的情况下，两次数据包对于数据包的完整性上有很大的优势）

post和put的区别

post一般用来提交数据，例如用户登录，创建新数据
put一般用来修改数据库的数据，修改数据

http常见响应状态码

1XX:continue 表示继续，一般在post请求的时候，浏览器先发送请求头过去之后，服务器会返回100表示继续发送，然后浏览器发送请求体
2XX：succes 成功状态码，表示请求正常处理完毕
3XX：Redirection 重定向 ，进行重定向后再完成请求
4XX: 客户端错误
5XX：服务端错误

404：not found 在服务器上没有找到所需要的资源

同样是重定向，307，303，302的区别？

302是http1.0的响应状态码，在http1.1中为了细化重定向出现了303和307, 303是表示客户端应该使用get请求获取数据，会将post请求转化为get请求进行重定向，而307不会将post改为get

HTTP状态码304是多好还是少好

当客户端在进行网络请求的时候，服务器会根据缓存内容判断页面有没有变化，如果没有变化的话就返回304，此时客户端调用缓存内容，不必进行二次下载。状态码304算不上是一种错误，他是在客户端有缓存的情况下，服务器向客户端发出的一种响应
304不一定多了好
网络爬虫会通过一段时间内网站返回的状态码来判断网页的质量，如果304缓存多了，就会降低蜘蛛对网站的抓取频次。相反，如果网站更新频率快，长此以往，回访率就会多
产生304原因：网站不更新或更新周期长

http报文格式

http请求报文和响应报文的格式结构基本相似，由三部分组成
1，请求行

2，请求头
是以 key-value形式的，比如前后端协商的传输的数据类型Content-type:applycation/json

3，消息正文（不是必须的）

content-type

MediaType（互联网媒体类型），在HTTP头中，会用content-type来表示请求或相应的数据的类型，也就是告诉服务器怎么处理请求的数据，告诉客户按怎么解析服务端响应的数据。
Content-Type的格式：
Content-Type：type/subtype ;parameter

type：主类型，任意的字符串，如text，如果是号代表所有；
subtype：子类型，任意的字符串，如html，如果是号代表所有，用“/”与主类型隔开；
parameter：可选参数，如charset，boundary等。

常见Content-Type

• HTML文档标记：text/html;
• js文档标记：application/javascript;
• xml文件标记：application/xml;
• JPEG图片标记：image/jpeg;
• GIF图片标记：image/gif;
• content-type:multipart/form-data 上传文件用这种格式
• application/json 参数为json格式
  {
  “key1”:“value1”,
  “key2”:“value2”
  }
• application/x-www-form-urlencoded
  HTTP会将请求参数用key1=val1&key2=val2的方式进行组织，并放到请求实体里面，注意如果是中文或特殊字符如"/“、”,“、“:” 等会自动进行URL转码。不支持文件，一般用于表单提交。
• multipart/form-data
  与application/x-www-form-urlencoded不同，这是一个多部分多媒体类型。首先生成了一个 boundary 用于分割不同的字段，在请求实体里每个参数以------boundary开始，然后是附加信息和参数名，然后是空行，最后是参数内容。多个参数将会有多个boundary块。如果参数是文件会有特别的文件域。最后以------boundary–为结束标识。multipart/form-data支持文件上传的格式，一般需要上传文件的表单则用该类型。

https

https是超文本传输安全协议，http利用http通讯，使用SSL/TLS来进行数据的加密
https主要目的是提供服务器的身份认证，保护将换的数据的安全性
他主要是在http和tcp之间加了一层安全层（SSL/TLS）,安全层主要对发出的http请求进行加密，对接收到的http内容进行解密

SSL/TLS工作原理

基于三个算法：非对称加密，对称加密，散列函数hash

• 使用非对称加密来进行身份认证和密钥协商
• 使用对称加密来对数据加密（对称加密就是通信双方使用同一个密钥进行加密解密）
• 使用散列算法来验证信息的完整性
  

SSL/TLS四次握手过程

客户端向服务器索要公钥并验证服务器的证书
双方协商生成会话密钥
双方采用会话密钥 对称加密进行加密通信
具体过程

• 客户端向服务器发起加密通信请求。客户端发送的信息有
  客户端支持的SSL/TLS协议版本
  随机数
  客户端支持的密码套件列表，如RSA加密算法。
• 服务器收到客户端请求后，向客户端发送响应。响应的内容有：
  确认SSL/TL协议版本 如果浏览器不支持就关闭加密通信
  随机数，用来后面生成会话密钥
  确认的密码套件列表
  服务器的数字证书。
• 客户端在收到服务器的响应后，通过提前植入浏览器或操作系统中的CA公钥，确认服务器的数字证书的真实性，来确认服务器是否是可信的。如果没有问题，从数字证书中取出服务器的公钥，使用它加密报文，向服务器发送信息：
  随机数，并且使用服务器
  加密通信算法改变通知，表示随后的信息都将使用 会话密钥 加密通信
  客户端握手结束通知，表示客户端的握手阶段已经结束。同时把之前所有内容的发生的数据做个摘要，供服务器检验。
• 服务器最后的回应，服务器收到客户端的第三个随机数后，通过协商的加密算法，计算出本次通信的 会话密钥，然后向客户端发送最后的信息：
  加密通信算法改变通知，表示随后的信息都适用 会话密钥 加密通信
  服务器握手结束通知，表示服务器的握手阶段已经结束。同时把之前所有内容的发生的数据做个摘要，供客户端检验
  SSL/TLS握手阶段结束，客户端和服务器进入加密通信，使用 会话密钥 进行加密

数字证书

证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期
对称加密：通信双方使用同一个密钥来加密解密数据，这样当首次发送密钥的时候容易泄露
非对称加密：使用公钥和私钥形成密钥对，使用私钥加密的数据要用公钥解密，使用公钥加密的数据要使用私钥来解密，因为通信双方都有自己的密钥对，通信之前可以先把自己的公钥发给对方，然后对方传输过来数据之后，再用自己的私钥解密（但是这样如果有一个中间人那原本双方的公钥换成自己公钥，那么这个中间人就可以解密通信双方的数据），所以这个时候就需要数字证书

使用 Hash 算法来对公钥和其他信息进行加密，生成一个信息摘要，然后让有公信力的认证中心（简称 CA ）用它的私钥对消息摘要加密，形成签名。最后将原始的信息和签名合在一起，称为数字证书。

HTTP 与 HTTPS区别

• HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全⻛险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在
  TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。
• HTTP 连接建⽴相对简单， TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。⽽ HTTPS 在 TCP 三次握⼿之
  后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。
• HTTP 的端⼝号是 80，HTTPS 的端⼝号是 443。
• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的

https 协议的缺点

• https 握手阶段比较费时，因为除了tcp握手以外，还要建立SSL/TLS握手
• https 缓存不如 http 高效，会增加数据开销。
• SSL 证书也需要钱，功能越强大的证书费用越高。
  SSL 证书需要绑定 IP，不能再同一个 ip 上绑定多个域名，ipv4 资源支持不了这种消耗。

为什么抓包工具可以看到 HTTPS 中的 数据 ？

https://blog.csdn.net/m0_46761060/article/details/125668640
抓包工具抓包的原理

• 首先抓包工具会提供出代理服务，客户端需要连接该代理；
• 客户端发出 HTTP 请求时，会经过抓包工具的代理，抓包工具将请求的原文进行展示；
• 抓包工具使用该原文将请求发送给服务器；
• 服务器返回结果给抓包工具，抓包工具将返回结果进行展示；
• 抓包工具将服务器返回的结果原样返回给客户端；
• 抓包工具就相当于个透明的中间人，数据经过的时候它一只手接到数据，然后另一只手把数据传出去。

对keep-alive的理解

HTTP1.0 中默认是在每次请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接，这就是短连接。当使用Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接，这就是长连接。

页面有多张图片，HTTP是怎样的加载表现？

在HTTP 1下，浏览器对一个域名下最大TCP连接数为6，所以会请求多次。可以用多域名部署解决。这样可以提高同时请求的数目，加快页面图片的获取速度。
在HTTP 2下，可以一瞬间加载出来很多资源，因为，HTTP2支持多路复用，可以在一个TCP连接中发送多个HTTP请求。

浏览器缓存(http缓存)

浏览器缓存是为了帮助服务器提高并发效率，避免浏览器在服务器获取很多重复的资源
缓存分为强缓存和协商缓存

强缓存（本地缓存）

当浏览器在向服务器发送请求时，浏览器会根据请求头来判断是否命中强缓存，如果命中，就不用发送请求到服务器，直接在缓存中取到数据，此时的状态码是200

协商缓存

如果没有命中强缓存，请求就会发送到服务器端，服务器会判断这个请求想要获取的资源有没有更新，如果没有更新，就返回304,这就是协商缓存

然后

如果协商缓存也没有命中的话服务器就会返回新的数据给浏览器，浏览器获取到资源，重新更新缓存

怎们控制缓存的

• 强缓存使用expires或cache-control字段来控制的
  • expires（http1.0）是缓存的最后期限，缓存超过这个时间就会失效，是一个绝对时间，所以如果更改了客户端的时间，缓存的时间 就会出现偏差，所以就有了cache-control
  • cache-control（http1.1）字段是相对时间，单位是s,当浏览器拿到资源后开始计时，他有max-age来控制虽大时间长度
    在HTTP/1.1中，Cache-Control主要用于控制网页缓存，其主要取值为:
    • public : 所有内容都被缓存 (客户端和代理服务器都可缓存)
    • private： 所有内容只有客户端可以缓存，Cache-Control的默认取值。
    • no-cache: 客户端缓存内容，但是是否使用缓存则需要经过协商缓存来验证决定
    • no-store: 所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
    • max-age=xxx (xxx is numeric): 缓存内容将在xxx秒后失效，这里是相对值
• 协商缓存是通过Last-Modify和Etag来判断数据是否从修改 Etag、If-None-Match Last-Modified、If-Modified-Since
  • Last-Modify是上一次数据修改的时间，在一次请求中，请求里会有记录上一次的Last-Modify的一个字段,如果服务器判断请求的这个字段和Last-Modify一样的话，说明数据没有修改。但是这个会有问题，因为Last-Modify它有时间精度，如果修改和发送时间很近，则会出现错误，所以就有了Etag字段
  • Etag 字段是校验码，数据改变一次他也会改变，所以服务器通过判断请求中的字段和Etag就可以判断数据有没有改变

前端储存方式

• cookies： 在HTML5标准前本地储存的主要⽅式，优点是兼容性好，请求头⾃带cookie⽅便，缺点是⼤⼩只有4k，⾃动请求头加⼊cookie浪费流量，每个domain限制20个cookie，使⽤起来麻烦，需要⾃⾏封装；
• localStorage：HTML5加⼊的以键值对(Key-Value)为标准的⽅式，优点是操作⽅便，永久性储存（除⾮⼿动删除），⼤⼩为5M，兼容IE8+ ；
• sessionStorage：与localStorage基本类似，区别是sessionStorage当⻚⾯关闭后会被清理，⽽且与cookie、localStorage不同，他不能在所有同源窗⼝中共享，是会话级别的储存⽅式；
• IndexedDB： 是被正式纳⼊HTML5标准的数据库储存⽅案，它是NoSQL数据库，⽤键值对进⾏储存，可以进⾏快速读取操作，⾮常适合web场景，同时⽤JavaScript进⾏操作会⾮常便。
  • 异步：IndexedDB 操作时不会锁死浏览器，用户依然可以进行其他操作，这与 LocalStorage 形成对比，后者的操作是同步的。异步设计是为了防止大量数据的读写，拖慢网页的表现。
• Web SQL：2010年被W3C废弃的本地数据库数据存储⽅案，但是主流浏览器（⽕狐除外）都已经有了相关的实现，web sql类似于SQLite，是真正意义上的关系型数据库，⽤sql进⾏操作，当我们⽤JavaScript时要进⾏转换，较为繁琐；

缓存存在计算机的哪里

• memory cache（css,js,图片）
  就是将资源缓存到 内存 中，等待下次访问时不需要重新下载资源，而是直接在内存中获取。关闭浏览器后，数据将不存在（被释放掉了），再次打开页面，不会出现from memory cache
• disk cache（文本）
  就是将资源缓存到 磁盘 上，等待下次访问时不用重新下载资源，而是直接在磁盘中获取，关闭浏览器，数据依然存在，此资源不会随着该页面的关闭而释放掉，下次打开仍然会是from disk cache
  memory cache的优先级高于disk cache，最后是请求网络资源

三级缓存原理

1. 先去内存看，如果有，直接加载

2. 如果内存没有，择取硬盘获取，如果有直接加载

3. 如果硬盘也没有，那么就进行网络请求

4. 加载到的资源缓存到硬盘和内存

DNS域名系统

将域名转化为IP名
DNS占用53号端口，同时使用TCP和UDP协议

• 在区域传输的时候用的是TCP协议，因为辅域名服务器一般会定时查看主域名服务器里面的数据有没有变化，如果有变化就进行数据同步
• 在域名解析的时候使用的是UDP协议，不用三次握手，响应更快

DNS完整的查询过程

首先会在浏览器的缓存里面找对应的IP地址，如果有的话就返回IP地址，没有的话就
在本地域名服务器里面找，有的话就返回IP地址，没有的话
本地域名服务器向根域名服务器发送请求，如果有的话就返回IP地址，没有的话就告诉本地域名服务器去哪个顶级域名服务器里面找
本地域名服务器向顶级域名服务器发送请求，如果有的话就返回IP地址，没有的话就告诉本地域名服务器去哪个权限域名服务器里面找
本地域名服务器向权限域名服务器发送请求，权限域名服务器返回相应的IP地址
本地域名服务器保存这个IP地址，以便下次使用
本地域名服务器将得到的IP地址返回给浏览器

迭代查询和递归查询

在向本地域名服务器发送请求是递归查询，本地域名服务器在向其他域名服务器发送请求时是迭代查询

从输入url到整个页面的解析的全过程

• 解析url： 首先会对 URL 进行解析

UDP 面向数据报协议

• UDP无连接，在发送数据之前不需要建立连接
• UDP使用最大努力交付，不保证可靠交付
• UDP面向报文，UDP把交付下来的报文添加首部之后交付给IP层，不合并不拆分
• UDP没有拥塞控制

TCP协议

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

• 面向连接：在正式传输数据之前，传输双方都必须先建立TCP连接
• 可靠：TCP有 确认和重传机制，数据排序，流量控制，拥塞控制
• 字节流：传输层把应用层传下来的数据看成是没有结构的字节流

为什么可靠？

• 重传机制：TCP 实现可靠传输的⽅式之⼀，是通过序列号与确认应答。在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回⼀个确认应答消息，表示已收到消息如果客户端在发送了数据之后一段时间内没有收到确认，则认为是数据丢失了，就会重传刚才的数据。TCP有超时计时器
• 以字节为单位的滑动窗口：窗⼝⼤⼩就是指⽆需等待确认应答，⽽可以继续发送数据的最⼤值，发送窗口在收到新的确认后可以向前移，描述发送窗口使用三个指针（把数据分为四个区域，已发送且已收到确认，已发送未收到确认，允许发送还未发送，不允许发送）
• 流量控制：让你发送方发送速率不要过快，这样接收方可以来得及接受，响应里的rwnd表示还能发多少字节
• 拥塞控制：客户端发生了超时重传，就认为发生了拥塞，
  拥塞控制的算法：cwnd拥塞窗口 ssthresh 慢启动门限
  1.慢开始
  2.拥塞避免
  3.快重传
  4.快恢复

慢开始：发送方开始发送数据时，采用慢开始算法，将拥塞窗口的值设置为1，接收方每收到对一个报文的确认，拥塞窗口的值就加1，这样每经过一个传输轮次，拥塞窗口的值就加倍。
拥塞避免：当拥塞窗口大于门限值，使用拥塞避免算法，每收到一个确认报文就+1/cwnd,每经过一个传输轮次，拥塞窗口就+1，拥塞窗口进行线性缓慢增长。
当出现超时重传，就判定为网络拥塞
调整门限值为当前拥塞窗口的一半，并且设置拥塞窗口为1，进入慢开始阶段
快重传：后续如果接收到了连续三个重复的确认时，就会判定不是出现网络拥塞，而是报文有丢失，就会立即重传报文。
快恢复：当发送方直到有报文的丢失的时候就会启动快恢复算法，将门限值设为拥塞窗口的一半，然后将拥塞窗口等于门限值

TCP 三次握手

客户端和服务器都需要知道各自可收发，因此需要三次握手。
⼀开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端⼝，处于 LISTEN 状态

• 第一次握手：客户端会随机初始化序号（ client_isn ），将此序号置于 TCP ⾸部的「序号」字段中，同时把 SYN 标志
  位置为 1 ，表示 SYN 报⽂。接着把第⼀个 SYN 报⽂发送给服务端，表示向服务端发起连接，该报⽂不
  包含应⽤层数据，之后客户端处于 同步已发送 状态
• 第二次握手：服务端收到客户端的 SYN 报⽂后，⾸先服务端也随机初始化⾃⼰的序号（ server_isn ），将此序号填⼊
  TCP ⾸部的「序号」字段中，其次把 TCP ⾸部的「确认应答号」字段填⼊ client_isn + 1 , 接着把 SYN
  和 ACK 标志位置为 1 。最后把该报⽂发给客户端，该报⽂也不包含应⽤层数据，之后服务端处于 同步收到 状态
• 第三次握手：客户端收到服务端报⽂后，还要向服务端回应最后⼀个应答报⽂，⾸先该应答报⽂ TCP ⾸部 ACK 标志位
  置为 1 ，其次「确认应答号」字段填⼊ server_isn + 1 ，最后把报⽂发送给服务端，这次报⽂可以携带客
  户到服务器的数据，之后客户端处于 已建立连接 状态。
  服务器收到客户端的应答报⽂后，也进⼊ 已建立连接 状态
  第三次握⼿是可以携带数据的，前两次握⼿是不可以携带数据的

为什么是三次握⼿？不是两次

• 防⽌旧的重复连接初始化造成混乱，两次就不能判断当前连接是否是历史连接，三次握⼿则可以在客户端（发送⽅）准备发送第三次
  报⽂时，客户端因有⾜够的上下⽂来判断当前连接是否是历史连接
• 同步序列号，当客户端发送携带「初始序列号」的 SYN 报⽂的时候，需要服务端回⼀个 ACK 应答报⽂，表示客户端的 SYN 报⽂已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，两次握⼿只保证了⼀⽅的初始序列号能被对⽅成功接收，没办法保证双⽅的初始序列号都能被确认接收
• 避免资源浪费，如果只有「两次握⼿」，当客户端的 SYN 请求连接在⽹络中阻塞，客户端没有接收到 ACK 报⽂，就会᯿新发
  送 SYN ，由于没有第三次握⼿，服务器不清楚客户端是否收到了⾃⼰发送的建⽴连接的 ACK 确认信号，所以
  每收到⼀个 SYN 就只能先主动建⽴⼀个连接，就会造成资源浪费

四次挥手

• 第一次挥手： 若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。
• 第二次挥手：服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。
• 第三次挥手：服务端如果此时还有没发完的数据会继续发送，完毕后服务器会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。
• 第四次挥手： 客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，连接关闭。
  客户端在经过2MSL（MSL报⽂最⼤⽣存时间）后，自动关闭连接

为什么要经过2MSL时间后，客户端才关闭连接？

MSL是报文最大生存时间，超过这个时间的报文就会被丢弃
因为⽹络中可能存在来⾃客户端的数据包，当这些客户端的数据包被接收⽅处理后⼜会向对⽅发送响应，所以⼀来⼀回需要等待 2 倍的时间。
为了确保最后一个ACK报文能够到达服务器。因为如果最后一个响应报文没有到达服务器的话，服务器会重新发送FIN报文，这个时候客户端可以继续发送应答报文，如果客户端没有经过2MSL的时间的话，服务器端没收到最后的应答报文就不能正常关闭

为什么要挥手四次？

因为TCP是基于连接的双全工的连接，传送双方都可以发数据和接收数据，关闭连接时，客户端向服务器端发送FIN，仅仅代表客户端不再向服务端发送数据，但是此时，服务器端还可以向服务端发送没有发送完的数据，当服务端发送完要发的数据后，在向客户端发送FIN，表示服务端不再发送数据了

TCP连接管理

1，TCP连接四元组：[源地址，源端口，目的地址，目的端口]

2，确立连接（TCP三次握手）

• 同步通讯双方初始序列号
• 协商TCP通讯参数（窗口信息，指定校验和算法）

TCP报文格式

说说 TCP 和 UDP 的区别

• TCP（Transmission control protocol，传输控制协议）是基于连接的协议，也就是说，在正式发送数据前，必须和对方建立可靠的连接。一个 TCP 连接必须要经过‘三次握手’才能建立起来
• UDP（User Datagram Protocol，用户数据报协议）是与 TCP 相对应的协议。它是面向非连接的协议，他不与对方建立连接，而是直接就把数据报发送出去。UDP 适用于一次只传送少量数据，对可靠性要求不高的应用环境。

当输入一个url到渲染页面的过程(http请求的完整过程)

• 解析url，判断url中的协议或主机名是否合法
• 缓存判断，浏览器会查看要请求的资源在不在缓存中，如果在缓存中，则使用缓存中的资源
• DNS解析，获取服务器的IP地址，
• 建立TCP连接，经过三次握手建立连接
• https握手，如果是https协议的话，还需要进行https握手，来确认加密方式还有检验服务端的数字证书是否有效
• 服务端返回数据，客户端下载数据
• 页面渲染，浏览器根据HTML文件建立DOM树，根据CSS生成样式模型，然后根据这两个树来建立渲染树，渲染树建立完成之后，就会将页面渲染出来

TLS(安全传输协议，会生成安全密钥，来保证通信安全)
TLS握手:交换密钥

网络攻击方式，怎么预防？

SQL注入

将恶意SQL代码混在用户提交的表单数据中或用户请求的查询字符串中，让服务器来执行恶意代码。

• 预防：在客户端对于用户的输入进行检查，在服务端可以对用户提交的信息进行过滤

xss攻击

网站对于恶意代码没有进行过滤，恶意代码会植入到用户的脚本中执行，就可以获取到用户的cookie，以及键盘输入的密码等私密信息

• 预防“给cookie设置http-only属性，只能用于发送http请求，js不能获取到cookie
  • 使用CSP（(Content-Security-Policy 白名单）告诉浏览器那些外部资源可以加载并执行
    开启 CSP：
    • 1，设置 HTTP Header 中的 Content-Security-Policy
    • 2，设置 meta 标签的方式

Content-Security-Policy: script-src ‘self’; object-src ‘none’;
style-src cdn.example.org third-party.org; child-src https:

< meta http-equiv=“Content-Security-Policy” content=“script-src ‘self’; object-src ‘none’; style-src cdn.example.org third-party.org; child-src https:”>

脚本：只信任当前域名
标签：不信任任何URL，即不加载任何资源
样式表：只信任cdn.example.org和third-party.org
框架（frame）：必须使用HTTPS协议加载
其他资源：没有限制
启用后，不符合 CSP 的外部资源就会被阻止加载。

限制选项:
资源加载限制
script-src：外部脚本
style-src：样式表
img-src：图像
media-src：媒体文件（音频和视频）
font-src：字体文件
object-src：插件（比如 Flash）
child-src：框架
frame-ancestors：嵌入的外部资源（比如、、和）
connect-src：HTTP 连接（通过 XHR、WebSockets、EventSource等）
worker-src：worker脚本
manifest-src：manifest 文件

CSRF攻击，跨站请求伪造

用户访问a.com保留了cookie,然后攻击者引诱用户访问b.com,b.com向a.com发起一个请求，浏览器会默认携带上a的cookie，服务器a会以为是用户自己发的请求，这样在用户不知道发送了一个请求

• 预防：使用Token验证身份，因为浏览器会自动携带上cookie,所以CSRF跨站请求伪造就会利用这一点来使用户的cookie,但是浏览器发送请求不会自动携带上token，所以使用token身份验证会预防CSRF攻击

什么是中间人攻击？如何防范中间人攻击？

中间⼈ (Man-in-the-middle attack, MITM) 是指攻击者与通讯的两端分别创建独⽴的联系, 并交换其所收到的数据, 使通讯的两端认为他们正在通过⼀个私密的连接与对⽅直接对话, 但事实上整个会话都被攻击者完全控制。在中间⼈攻击中，攻击者可以拦截通讯双⽅的通话并插⼊新的内容。
攻击过程如下:

客户端发送请求到服务端，请求被中间⼈截获
服务器向客户端发送公钥
中间⼈截获公钥，保留在⾃⼰⼿上。然后⾃⼰⽣成⼀个伪造的公钥，发给客户端
客户端收到伪造的公钥后，⽣成加密hash值发给服务器
中间⼈获得加密hash值，⽤⾃⼰的私钥解密获得真秘钥,同时⽣成假的加密hash值，发给服务器
服务器⽤私钥解密获得假密钥,然后加密数据传输给客户端

7. 网络劫持有哪几种，如何防范？

⽹络劫持分为两种:
（1）DNS劫持: (输⼊京东被强制跳转到淘宝这就属于dns劫持)

DNS强制解析: 通过修改运营商的本地DNS记录，来引导⽤户流量到缓存服务器
302跳转的⽅式: 通过监控⽹络出⼝的流量，分析判断哪些内容是可以进⾏劫持处理的,再对劫持的内存发起302跳转的回复，引导⽤户获取内容
解决方法：

• 更换DNS域名服务器
• 如果知道对应服务器的IP地址，就在host文件里面修改
• DNS加速类产品，因为DNS域名服务器里面的缓存有时间限制，用加速器可以刷新DNS的缓存，从而降低DNS劫持的概率

（2）HTTP劫持: (访问⾕歌但是⼀直有贪玩蓝⽉的⼴告),由于http明⽂传输,运营商会修改你的http响应内容(即加⼴告)
DNS劫持由于涉嫌违法，已经被监管起来，现在很少会有DNS劫持，⽽http劫持依然⾮常盛⾏，最有效的办法就是全站HTTPS，将HTTP加密，这使得运营商⽆法获取明⽂，就⽆法劫持你的响应内容。

cookie的secure属性和httpOnly属性

1 secure属性
当设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是 HTTP 连接则不会传递该信息，所以不会被窃取到Cookie 的具体内容。
2 HttpOnly属性
如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这样能有效的防止XSS攻击。

状态码

100：这个状态码是告诉客户端应该继续发送请求，这个临时响应是用来通知客户端的，部分的请求服务器已经接受，但是客户端应继续发送求请求的剩余部分，如果请求已经完成，就忽略这个响应，而且服务器会在请求完成后向客户发送一个最终的结果
2XX 成功
· 200 OK，表示从客户端发来的请求在服务器端被正确处理，并将返回客户请求的资源
· 202 表示已经收到请求了，但是还没有处理，而且这个请求会不会被处理还不一定
· 204 No content，表示请求成功，但是返回的响应中没有实体内容
· 206 Partial Content，继续请求一个未完成的下载的时候，一般在这提示用户用不要继续下载
3XX 重定向
· 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
· 302 found，临时性重定向，表示资源临时被分配了新的 URL
· 303 see other，表示资源存在着另一个 URL，应使用 GET 方法定向获取资源
· 304 not modified，命中了协商缓存
· 307 temporary redirect，临时重定向，和302含义相同，但是307不会改变请求方式，不会吧post请求变为Get请求
4XX 客户端错误
· 400 bad request，请求报文存在语法错误
· 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息，需要有效的token
· 403 forbidden，表示对请求资源的访问被服务器拒绝
· 404 not found，表示在服务器上没有找到请求的资源
· 405 该状态码表示客户端请求的方法虽然能被服务器识别，但是服务器禁止使用该方法。
5XX 服务器错误
· 500 internal sever error，表示服务器端在执行请求时发生了错误
· 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求
· 505 Gateway Timeout 代码执行时间超时，或者发生了死循环。

如何排查504：Gateway Timeout

代码执行时间超时，或者发生了死循环