网络
从浏览器链接到网页展示的过程中发生了什么
- 输入地址
- 浏览器查找域名的 IP 地址
host文件、本地的DNS服务器、DNS根服务器、域服务器 - 浏览器向 web 服务器发送一个 HTTP 请求，建立TCP连接
- 服务器处理请求，返回一个 HTTP 响应
- 返回HTML网页，浏览器渲染显示网页
- 浏览器发送请求获取嵌入在 HTML 中的资源（如图片、音频、视频、CSS、JS等等）
TODO 网络白屏如何排查
网络架构
HTTP错误码
- 301 Moved Permanently：所请求的资源已永久移动到新的位置。
- 302 Found (Also known as Moved Temporarily)：所请求的资源已临时移动到新的位置。
- 400 Bad Request：服务器无法理解客户端的请求，可能因为语法错误。
- 401 Unauthorized：请求需要用户的身份验证。
- 402 Payment Required：此状态码是为了将来可能的需求而预留的。原始的 HTTP/1.1 规范提出，402 状态码将用于实现数字货币支付，但现实中该状态码很少被使用。
- 403 Forbidden：服务器理解了请求，但是拒绝执行。
- 404 Not Found：请求的资源在服务器上找不到。
- 405 Method Not Allowed：请求的方法（GET、POST、HEAD、DELETE、PUT、等等）对于所请求的资源是禁止的。
- 429 Too Many Requests：用户在给定的时间内发送了太多的请求（”限制请求速率”）。
- 499 Client Closed Request：这个状态码一般出现在nginx中，表示客户端在服务器端没有完成处理前就已经关闭了连接。
- 500 Internal Server Error：服务器遇到了一个未知的错误，无法完成请求。
- 501 Not Implemented：服务器不支持请求中所使用的方法。
- 502 Bad Gateway：服务器作为网关或代理，从上游服务器收到的响应是无效的。
- 503 Service Unavailable：服务器目前无法使用（由于过载或停机维护）。通常，这只是暂时的状态。
- 504 Gateway Timeout：服务器作为网关或代理，但是没有及时从上游服务器收到请求。
- 505 HTTP Version Not Supported：服务器不支持请求中所指明的HTTP版本。
HTTP 1.0和 HTTP1.1的区别 & 长链接和短连接
https://blog.csdn.net/yangyingjian123/article/details/115409482
在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。应用场景是并发量大，但每个用户无需频繁操作情况下。
而从HTTP/1.1起，默认使用长连接。长连接的HTTP协议，会在响应头加入Connection:keep-alive。当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。它的保持时间是在服务器中设定的。长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。缺点是存活功能的探测周期太长，随着客户端连接越来越多，server的压力太大。多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。
三次握手
第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号ISN。此时客户端处于 SYN_SEND 状态。
第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。
第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
三次握手是为了保证客户端和服务器的接收与发送能力是否正常。如果是两次握手，则会出现下面这种情况：
客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一直等待客户端发送数据，浪费资源。
四次挥手
四次挥手的过程如下：刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求。
第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
为什么？关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。
最后更新于 2023年7月24日 by qlili
