计算机网络整理

网络分层

OSI 七层模型及每层简要功能描述

7-应用层（Application Layer）

任务：提供为应用软件设计的接口。
功能：文件传输、电子邮件。
例如：HTTP、HTTPS、FTP、Telnet、SSH、SMTP、POP3 、DNS 等。

6-表示层（Presentation Layer）

任务：负责处理在两个内部数据表示结构不同的通信系统之间交换信息的表示格式，为数据加密和解密以及为提高传输效率提供必需的数据压缩以及解压等功能。

5-会话层（Session Layer）

任务：不同主机上各进程间对话
功能：管理主机间的会话进程，包括建立、管理以及终止进程间的会话。是一种端到端的服务。

4-传输层（Transport Layer）

任务：负责主机中两个进程之间的通信
功能：为端到端连接提供可靠的服务；为端到端连接提供流量控制、差错控制、服务质量等管理服务。
传输单位：报文段（TCP）或用户数据报（UDP）
协议：TCP、UDP

a. 复用，就是多个应用层进程可同时使用下面运输层的服务。
b. 分用，就是把收到的信息分别交付给上面应用层中相应的进程。

3-网络层（Network Layer）

任务：将传输层传输的报文封装成分组，选择合适的路由将分组传输到目的主机
功能：路由选择、拥塞控制。
协议：ICMP、ARP、RARP、IP、IGMP、OSPF

2-数据链路层（Data Link Layer）

任务：将网络层传输的 IP 数据包组装成帧。
功能：数据链路建立、拆除；帧定界和帧同步；差错检测。
硬件：交换机和网桥。
协议：PPP、HDLC、SDLC、STP、ARQ

1-物理层（Physical Layer）

任务：透明地传输比特流。
硬件：集线器、中继器等。

五层网络体系模型

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

网络层协议

网络层：IP、ICMP、IGMP、RIP

ICMP 协议
深入理解 ICMP 协议 - 知乎

ICMP 是 Internet Control Message Protocol 的缩写，即互联网控制消息协议。
用于 TCP/IP 网络中发送控制消息，提供问题反馈。
ICMP 协议包含两大类，查询报文和查错报文。查询报文 - 查询时的请求+应答。差错报文 - 错误信息。
通过类型+代码的形式 (类似 HTTP 状态码) 来标志不同的信息。
ICMP 报文被封装到 IP 数据包中，形式如下：
ICMP 最典型的应用就是 Ping 命令。发送查询请求，返回查询应答 or 差错报文。⇒ 是否可达，来回的延迟，丢包情况。

IGMP 协议

因特网组管理协议（Internet Group Manage Protocol，IGMP）被设计用来在主机和本地的组播路由器之间交换组播信息。

RIP 协议
RIP 协议原理，请认真看完！ - 腾讯云开发者社区-腾讯云

RIP (Routing Information Protocol, 路由信息协议），是一种动态路由选择协议。
通过距离矢量算法与相邻路由器交换信息来动态更新路由选择，范围限制在 15 跳内，15 跳外认为不可达。
实际使用中较少适用。

ARP 协议

ARP（Address Resolution Protocol）地址解析协议，是根据 IP 地址获取物理地址的一个 TCP/IP 协议。
在 OSI 模型中 ARP 协议属于链路层，而在 TCP/IP 模型中，ARP 协议属于网络层
ARP 就是一种解决地址问题的协议，它以 IP 地址为线索，定位下一个应该接收数据分包的主机 MAC 地址。如果目标主机不在同一个链路上，那么会查找下一跳路由器的 MAC 地址。
主机 A 想要获取主机 B 的 MAC 地址，通过主机 A 会通过 广播 的方式向以太网上的所有主机发送一个 ARP 请求包，这个 ARP 请求包中包含了主机 A 想要知道的主机 B 的 IP 地址的 MAC 地址。

网络分层有什么好处

1）各层之间是独立的。某一层并不需要知道它下一层是如何实现的，而仅仅需要知道该层通过层间的接口所提供的服务。由于每一层只实现一种相对独立的功能，因而可以将一个难以处理的复杂问题分解为若干个较容易处理的更小问题，这样，整个问题的复杂度就下降了。
2）灵活性好。当任何一层发生变化时，只要层间接口关系保持不变，则在这层以上或以下各层均不受影响，此外，对某一层提供的服务还可以进行修改。当某层提供的服务不再需要时，甚至可以将这层取消。
3）结构上可分割开。各层都可以采用最合适的技术来实现。
4）易于实现和维护。这种结构使得实现和调试一个庞大而又复杂的系统变得易于处理，因为整个系统已被分解为若干个相对独立的子系统。
5）能促进标准化工作。因为每一层的功能及其所提供的服务都已有了精确的说明。

客户端发送给服务端的请求，怎么确定具体的协议？

URL 包含，协议部分、网址部分、文件地址或请求参数。协议部分对应具体协议，如 http://www.baidu.com 对应 http 协议。

TCP/IP 协议

TCP/IP 协议的定义

TCP/IP（Transmission Control Protocol/Internet Protocol，传输控制协议/网际协议）是指能够在多个不同网络间实现信息传输的协议簇。TCP/IP 协议不仅仅指的是 TCP 和 IP 两个协议，而是指一个由 FTP、SMTP、TCP、UDP、IP 等协议构成的协议簇，只是因为在 TCP/IP 协议中 TCP 协议和 IP 协议最具代表性，所以被称为 TCP/IP 协议。

TCP/IP 协议的组成 or TCP/IP 结构模型

TCP/IP 结构模型分为应用层、传输层、网络层、链路层（网络接口层） 四层。
应用层对应应用、表示、会话层。
传输层对应传输层。
网络层对应网络层。
链路层对应物理层和数据链路层。

TCP/IP 的基本工作原理 OR 应用层报文怎么传输到另一个应用层

1，TCP/IP 的结构模型。
2，封装和解封。

应用层报文向下一层层进行封装后到达物理层，经过物理层进行传输，之后向上一层层解封后发给应用层。
封装过程：

解封过程：
(期间要检查校验和)

HTTP 协议

HTTP 1.0 / 1.1 / 2.0 / 3.0 区别和特点

HTTP 1.0 特点
无状态、无连接的应用层协议，每个请求都要建立一个 TCP 连接。这种无状态性可以借助 cookie/session 机制来做身份认证和状态记录。
HTTP 1.0 问题
每个请求都要新建连接，无法复用连接。
队头阻塞机制，前一个请求接受到相应后才能发送下一个，若前一个请求相应未接受到那么就会阻塞。
不支持断点续传，每次都会传送全部的页面和数据。

HTTP 1.1 特点
HTTP 1.1 是长连接，通过 Connection=keep alive 字段来保持连接不断，提高网络连接的利用率。
HTTP 1.1 的长连接支持流水线和非流水线方式，即是否等待前一个请求的相应到达再发送下一个请求。
HTTP 1.1 支持断点续传，增加了错误状态响应码，引入更多缓存策略。
HTTP 1.1 可以使用管道传输，同时发送多个请求，服务器按顺序响应请求，但若响应较慢，仍有队头堵塞。

HTTP 2.0 特点
二进制分帧技术。在应用层和传输层之间增加二进制分层帧，突破 HTTP1.1 性能限制，改进了传输性能。

多路复用 (链接共享)— 真并行传输

多路复用 (或连接共享)，使用多个 stream，每个 stream 又分帧传输，使得一个 tcp 连接能够处理多个 http 请求

流 (stream)：已建立连接上的双向字节流；
消息：与逻辑消息对应的完整的一系列数据帧；
帧 (frame)：HTTP2.0 通信的最小单位，每个帧包含头部，至少也会标识出当前所属的流 (stream_id)。
所有 HTTP2.0 通信都在一个 TCP 链接上完成，这个链接可以承载任意流量的双向数据流。
每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符 (Stream_id) 重新封装。
多路复用 (连接共享) 可能会导致关键字被阻塞，HTTP 2.0 里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回客户端，数据流还可以依赖其他的子数据流。
可见，HTTP2.0 实现了真正的并行传输，它能够在一个 TCP 上进行任意数量的 HTTP 请求。而这个强大的功能基于“二进制分帧”的特性。

头部压缩技术。使用 encoder 来减少需要传输的 header 大小，通讯双方各自缓存一份 header 首部表，传输时仅仅传输 header 中变化的部分，避免重复数据传输。同时新增了压缩算法，可以很大程度上压缩 header。

服务器推送技术。服务器还可以额外向客户端推送资源，而无需客户端明确的需求。
深入理解 http2.0 协议，看这篇就够了！

HTTP 3.0 特点
HTTP3 背后的主要思想是放弃 TCP，转而使用基于 UDP 的 QUIC 协议。
与 HTTP2 在技术上允许未加密的通信不同，QUIC 严格要求加密后才能建立连接。此外，加密不仅适用于 HTTP 负载，还适用于流经连接的所有数据，从而避免了一大堆安全问题。建立持久连接、协商加密协议，甚至发送第一批数据都被合并到 QUIC 中的单个请求/响应周期中，从而大大减少了连接等待时间。如果客户端具有本地缓存的密码参数，则可以通过简化的握手（0-RTT）重新建立与已知主机的连接。
为了解决传输级别的线头阻塞问题，通过 QUIC 连接传输的数据被分为一些流。流是持久性 QUIC 连接中短暂、独立的“子连接”。每个流都处理自己的错误纠正和传递保证，但使用连接全局压缩和加密属性。每个客户端发起的 HTTP 请求都在单独的流上运行，因此丢失数据包不会影响其他流/请求的数据传输。

基于 google 的 QUIC 协议，而 quic 协议是使用 udp 实现的；
减少了 tcp 三次握手时间，以及 tls 握手时间；
解决了 http 2.0 中前一个 stream 丢包导致后一个 stream 被阻塞的问题；
优化了重传策略，重传包和原包的编号不同，降低后续重传计算的消耗；
连接迁移，不再用 tcp 四元组确定一个连接，而是用一个 64 位随机数来确定这个连接；
更合适的流量控制。

HTTP 请求报文和响应报文格式

HTTP 请求报文由请求行（request line）、请求头部（header）、空行和请求数据 4 个部分组成
请求行由请求方法、URI 和 HTTP 协议版本 3 个字段组成，它们用空格分隔。

GET/sample.jspHTTP/1.1 请求行
Accept: image/gif.image/jpeg, 请求头部
Accept-Language: zh-cn
Connection: Keep-Alive
Host:localhost
User-Agent: Mozila/4.0 (compatible; MSIE5.01; Window NT5.0)
Accept-Encoding: gzip, deflate
 
username=jinqiao&password=1234 请求主体

HTTP 响应报文也由 4 个部分组成，分别是：状态行、响应头部、空行和响应正文。
响应行由 HTTP 协议版本、状态码和状态码描述 3 个字段组成，它们用空格分隔。

HTTP/1.1 200 OK
Server: Apache Tomcat/5.0.12
Date: Mon, 6Oct2003 13:23:42 GMT
Content-Length:112
 
<html>
    <head>
        <title>HTTP响应示例<title>
    </head>
    <body>
        Hello HTTP!
    </body>
</html>

HTTP 请求方法

HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。

HTTP1.1 新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法

1、OPTIONS

返回服务器针对特定资源所支持的 HTTP 请求方法，也可以利用向 web 服务器发送\‘*\’的请求来测试服务器的功能性

2、HEAD

向服务器索与 GET 请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。

3、GET

向特定的资源发出请求。注意：GET 方法不应当被用于产生“副作用”的操作中，例如在 Web Application 中，其中一个原因是 GET 可能会被网络蜘蛛等随意访问。Loadrunner 中对应 get 请求函数：web_link 和 web_url

4、POST

向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner 中对应 POST 请求函数：web_submit_data, web_submit_form

5、PUT

向指定资源位置上传其最新内容

6、DELETE

请求服务器删除 Request-URL 所标识的资源

7、TRACE

回显服务器收到的请求，主要用于测试或诊断

8、CONNECT

HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。

HTTP 请求方法中 Get 和 Post 的区别

get 和 post 最大的区别就是 get 请求是幂等性的，post 请求不是。幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一 URL 的多个请求应该返回同样的结果。

区别：重新发送、书签&历史记录&缓存、编码类型、数据长度、数据类型、安全性&可见性。

	GET	POST
后退按钮/刷新	无害	数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
书签	可收藏为书签	不可收藏为书签
缓存	能被缓存	不能缓存
编码类型	application/x- www-form-urlencoded	application/x- www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史	参数保留在浏览器历史中。	参数不会保存在浏览器历史中。
对数据长度的限制	当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。	无限制。
对数据类型的限制	只允许 ASCII 字符。	没有限制。也允许二进制数据。
安全性	与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET ！	POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性	数据在 URL 中对所有人都是可见的。	数据不会显示在 URL 中。

HTTP 常见状态码及含义

1XX 信息

100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2XX 成功

200 OK： 请求被正常处理并返回；
204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。（一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。）
206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

3XX 重定向

301 Moved Permanently ：永久性重定向，表示请求的资源被分配了新的 URL，之后应使用更改的 URL；
302 Found ：临时性重定向，表示请求的资源被分配了新的 URL，希望本次访问使用新的 URL；

301 与 302 的区别：前者是永久移动，后者是临时移动（之后可能还会更改 URL）
303 See Other ：表示请求的资源被分配了新的 URL，应使用 GET 方法定向获取请求的资源；

302 与 303 的区别：后者明确表示客户端应当采用 GET 方式获取资源
304 Not Modified ：一般是 HTTP 对比缓存时，客户端不确定缓存是否是最新版本，因此会发送条件请求。请求报文的首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since。如果服务端表示缓存为最新的，则发送 304 状态码，响应主体为空。如果服务端表示缓存不是最新的，则发送 200 状态码，响应主体包含新缓存。
307 Temporary Redirect ：临时重定向，与 303 的含义类似，307 会遵照浏览器标准不会从 POST 变成 GET；（不同浏览器可能会出现不同的情况）；

4XX 客户端错误

400 Bad Request ：请求报文中存在语法错误。
401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
403 Forbidden ：请求被拒绝。
404 Not Found：表示服务器上无法找到请求的资源。

5XX 服务器错误

500 Internal Server Error ：服务器正在执行请求时发生错误。
503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

重定向和转发的区别

地址显示、数据访问、运用场景、效率。

地址栏显示
1. forward - 地址栏地址不变，一次请求
2. redirect - 地址栏显示新地址，两次请求
数据共享
1. forward - 页面共享 request 中的数据
2. redirect - 两个请求，不能共享数据
运用场景
1. forward - 用户登陆，将角色转发到相应模块
2. redirect - 注销时跳转其他网站
效率
1. forward - 效率高
2. redirect - 效率低

转发过程：客户浏览器发送 http 请求----》web 服务器接受此请求—》调用内部的一个方法在容器内部完成请求处理和转发动作----》将目标资源发送给客户; 在这里，转发的路径必须是同一个 web 容器下的 url，其不能转向到其他的 web 路径上去，中间传递的是自己的容器内的 request。在客户浏览器路径栏显示的仍然是其第一次访问的路径，也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。

重定向过程：客户浏览器发送 http 请求----》web 服务器接受后发送 302 状态码响应及对应新的 location 给客户浏览器—》客户浏览器发现是 302 响应，则自动再发送一个新的 http 请求，请求 url 是新的 location 地址----》服务器根据此请求寻找资源并发送给客户。在这里 location 可以重定向到任意 URL，既然是浏览器重新发出了请求，则就没有什么 request 传递的概念了。在客户浏览器路径栏显示的是其重定向的路径，客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次的访问请求的。

HTTP 短连接 vs 长连接

HTTP 短连接是指，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。例如，访问一个页面，再访问页面中的 Web 资源会重新建立 HTTP 连接。

HTTP 长连接是指，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。例如，访问一个页面，再访问页面中的 Web 资源，会继续使用之前的 HTTP 连接。通过设置 Connection:keep-alive 来设置 HTTP 长连接。不过并非永久保存连接，会有一个保持时间。

HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。

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

服务端给每个连接都创建了 Session，用这个 Session 来标志和跟踪这个用户，一般使用 Redis 来将 Session 和用户进行匹配。同时，会将 Session 数据附加在 Cookie 中，客户端发送请求时携带 Cookie，服务端读取 Cookie 中的 Session 就可以继续跟踪这个用户。
Cookie 被禁用怎么办? 最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

Cookie、Session 的概念、作用、区别、配合

Cookie 概念：
服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

Cookie 作用：

自动填写表单
保存登录信息，下次不需要重新登录（根据 Token 标志用户，登陆时根据 Token 来查找用户，一般重新登录需要重写 Token）
登录一次网站后，其他页面无需登录。

Session 概念：
Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。

区别：

存储位置。Cookie 存储在客户端中，而 Session 存储在服务器上。
编码方式。Cookie 只能 Ascii，Session 可以任意格式。
有效期不同。Cookie 长期有效，Session 可能失效。
安全性。相对来说 Session 安全性更高。
存储大小。Cookie 数据有限，不超过 4K。Session 远高于 Cookie。

配合：

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。
当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

Session ID 创建时间、生成方法、存储位置、销毁

创建时间：
浏览器第一次访问服务器会在服务器端生成一个 session，session 在访问 tomcat 服务器 HttpServletRequest 的 getSession (true) 的时候创建。

生成方法：
随机数 + 时间 + JVM ID

存储位置:
服务端将其存储在内存中，也可以进行持久化；客户端将 session id 保存到 cookie 中。

销毁：

通过关闭浏览器不会销毁 session id

过期
invalidate
程序关闭

分布式 Session 问题

分布式 Session 出现的问题：

多台服务器提供服务，第一次请求在 A 服务器登录，第二次请求在 B 服务器可能登录失效。

分布式 Session 解决方案:

客户端存储: 直接将信息存储在 cookie 中，cookie 是存储在客户端上的一小段数据，客户端通过 http 协议和服务器进行 cookie 交互，通常用来存储一些不敏感信息
Nginx ip_hash 策略: 服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。
Session 复制: 任何一个服务器上的 Session 发生改变（增删改)，该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。
共享 Session: 服务端无状态话，将用户的 Session 等信息使用缓存中间件（如 Redis〉来统一管理，保障分发到每一个服务器的响应结果都一致。

HTTPS 连接过程

客户端发送请求到服务器端
服务器端返回证书和公开密钥，公开密钥作为证书的一部分而存在，同时自己保留一个私有密钥
客户端验证证书和公开密钥的有效性，如果有效，则生成共享密钥并使用公开密钥加密发送到服务器端
服务器端使用私有密钥解密数据，并使用收到的共享密钥加密数据，发送到客户端
客户端使用共享密钥解密数据
SSL 加密建立…

HTTPS = HTTP + SSL 协议

数据是加密的，无法获得真实数据
篡改数据会被接收端感知到
证书难以伪造

HTTP 和 HTTPS 的区别

端口：HTTP 的 URL 由“http://”起始且默认使用端口 80，而 HTTPS 的 URL 由“https://”起始且默认使用端口 443。
安全性和资源消耗： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。
HTTPS 运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

对称加密 VS 非对称加密

对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有 DES、3DES、AES、RC 等；
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有 RSA、DSA 等。
DES - Data Encryption Standard 数据加密标准
AES - Advanced Encryption Standard
RSA - 罗纳德·李维斯特（Ron Rivest）、阿迪·萨莫尔（Adi Shamir）和伦纳德·阿德曼（Leonard Adleman）
DSA - Digital Signature Algorithm

HTTPS 的优缺点

优点:

安全性:
- 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器;
- HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 http 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
- HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
SEO 方面: 谷歌曾在 2014 年 8 月份调整搜索引擎算法，并称“比起同等 HTTP 网站，采用 HTTPS 加密的网站在搜索结果中的排名将会更高”。

缺点:

时间+资源成本增加
只能保证数据不被篡改、监听，但对于黑客攻击、服务器劫持起不到作用。
在现有的证书机制下，中间人攻击依然有可能发生。

DDos 攻击原理及防护

DDos 全称 Distributed Denial of Service，分布式拒绝服务攻击。

最基本的 DOS 攻击过程如下:

客户端向服务端发送请求链接数据包。
服务端向客户端发送确认数据包。
客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认。

DDoS 则是采用分布式的方法，通过在网络上占领多台”肉鸡”，用多台计算机发起攻击。
DOS 攻击现在基本没啥作用了，因为服务器的性能都很好，而且是多台服务器共同作用，1V1 的模式黑客无法占上风。

对于 DDOS 攻击，预防方法有:

减少 SYN timeout 时间。在握手的第三步，服务器会等待 30 秒-120 秒的时间，减少这个等待时间就能释放更多的资源。
限制同时打开的 SYN 半连接数目。

XSS 攻击和 CSRF 攻击原理及防护

XSS 概念及原理： 跨站脚本攻击（Cross Site Scripting）。指的是攻击者往 Web 页面中插入恶意 Script 代码，当用户浏览该页时，嵌入 Web 里面的 Script 代码会被执行，从而达到恶意攻击用户的目的。类似于 SQL 注入。

XSS 预防：

innerHTML 改成 innerText
对数据进行 HTML 实体编码。如使用 innerHTML，采用 HTML 转义处理，如：
- 把 > 替换成 &gt; 把 < 替换成 &lt; 把 & 替换成 &amp; 把 ” 替换成 &quot; 把 ’ 替换成 &#39;
字符过滤
- 过滤掉特殊的 HTML 标签，例如 <script> 、 <iframe> 等；过滤掉 Javascript 事件标签，例如”onclick”、“onfocus”等。

CSRF 概念及原理： 跨站点请求伪造（Cross-Site Request Forgery）。用户正常登录访问受信网站 A，网站 A 产生 cookie 返回到浏览器。同时，在相同浏览器访问网站 B，网站 B 返回攻击性代码请求要求访问第三方站点 A；在用户不知情下携带 Cookie 信息，向网站 A 发出请求。站点 A 并不知道该请求是由 B 发起的，会根据用户的 Cookie 信息以用户的权限处理该请求，导致来自站点 B 的恶意代码被执行。

CSRF 预防：

A. 将 cookie 设置为 HttpOnly，程序就无法读取 cookie，避免伪造。
B. 验证 HTTP Referer 字段，判断来源地址。
C. 在请求中添加 token 验证，避免黑客伪造。

HTTP 缓存

HTTP 缓存的类型很多，根据是否需要重新向服务器发起请求来分类包括两种：强制缓存和对比缓存。

强制缓存概念
在缓存数据未失效的情况下，可以直接使用缓存数据，不需要再请求服务器。对于强制缓存来说，响应 header 中会有两个字段来标明失效规则（Expires/Cache-Control）。
Expires 字段，用于 HTTP 1.0，它的值为到期时间。在 HTTP 1.1 的版本，Expires 被 Cache-Control 替代。
Cache-Control 字段，常见的取值有 private、public、max-age、no-cache，no-store，默认为 private。
1) max-age：用来设置资源（representations）可以被缓存多长时间，单位为秒；
2) s-maxage：和 max-age 是一样的，不过它只针对代理服务器缓存而言；
3) public：指示响应可被任何缓存区缓存；
4) private：只能针对个人用户，而不能被代理服务器缓存；
5) no-cache：强制客户端直接向服务器发送请求, 也就是说每次请求都必须向服务器发送。具体为，先缓存本地，但是在命中缓存之后必须与服务器验证缓存的新鲜度才能使用。 6) no-store：禁止一切缓存。

对比缓存
对比缓存，顾名思义，需要进行比较判断是否可以使用缓存。
浏览器第一次请求数据时，服务器会将缓存标识与数据一起返回给浏览器，浏览器将二者备份至缓存数据库中。
当浏览器再次请求数据时，浏览器将备份的缓存标识发送给服务器，服务器根据缓存标识进行判断，判断成功后，返回 304 状态码，通知客户端比较成功，可以使用缓存数据。

例如页面资源的缓存。

参考连接：从未如此简单：5 分钟搞懂 HTTP 缓存机制 - 云+社区 - 腾讯云

Socket 通信

socket 通信的具体步骤

sockets（套接字）编程有三种：流式套接字（SOCK_STREAM），数据报套接字（SOCK_DGRAM），原始套接字（SOCK_RAW）；基于 TCP 的 socket 编程是采用的流式套接字。

服务器端编程的步骤
（1）加载套接字库，创建套接字 (WSAStartup ()/socket ())；
（2）绑定套接字到一个 IP 地址和一个端口上 (bind ())；
（3）将套接字设置为监听模式等待连接请求 (listen ())；
（4）请求到来后，接受连接请求，返回一个新的对应于此次连接的套接字 (accept ())；
（5）用返回的套接字和客户端进行通信 (send ()/recv ())；
（6）返回，等待另一连接请求；
（7）关闭套接字，关闭加载的套接字库 (closesocket ()/WSACleanup ())。
客户端编程的步骤：
（1）加载套接字库，创建套接字 (WSAStartup ()/socket ())；
（2）向服务器发出连接请求 (connect ())；
（3）和服务器端进行通信 (send ()/recv ())；
（4）关闭套接字，关闭加载的套接字库 (closesocket ()/WSACleanup ())。

服务端怎么提高处理 socket 连接的性能

提高处理 socket 连接的性能，请遵循以下技巧：

最小化报文传输的延时。
最小化系统调用的负载。
为 Bandwidth Delay Product 调节 TCP 窗口。
动态优化 GNU/Linux TCP/IP 栈。

DNS

DNS 的递归查询和迭代查询

迭代查询：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。本地域名服务器根据给出的域名服务器继续查询。A 问 B，A 问 C，A 问 D。
递归查询：如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址，那么本地域名服务器就以 DNS 客户的身份，向其它根域名服务器继续发出查询请求报文 (即替主机继续查询)，而不是让主机自己进行下一步查询。A 问 B，B 问 C，C 问 D。
客户端-本地 dns 服务：这部分属于递归查询。
本地 dns 服务---外网：这部分属于迭代查询。

DNS 解析过程

DNS，全程 Domain Name System，即域名系统。作用是将域名与 IP 地址进行匹配。

浏览器中输入地址
浏览器的 DNS 缓存》（查找是否有对应的 ip 有的话解析完成没有的话下一步）
操作系统的 DNS 缓存》（查找是否有对应的 ip 有的话解析完成没有的话下一步）
本地 host 文件》（查找是否有对应的 ip 有的话解析完成没有的话下一步）
本地 DNS 服务器的 DNS 缓存》（查找是否有对应的 ip 有的话解析完成没有的话就拿着域名去根 DNS 服务器中询问）
根 DNS 服务器》（根 DNS 服务器会告诉本地 DNS 服务器，顶级 DNS 服务器的 ip 地址）
本地 DNS 服务器》（拿着域名去找顶级 DNS 服务器）
顶级 DNS 服务器》（顶级 DNS 服务器会告诉本地 DNS 服务器，本地 DNS 权威域名服务器的 ip 地址）
本地 DNS 服务器》（拿着域名去找本地 DNS 权威域名服务器最终拿到 ip 地址返回给浏览器）
浏览器（浏览器拿到 ip 地址后整个 DNS 解析过程就完成了）

本地 DNS 服务器，可以理解为连接校园网时，访问学校的官方网站时，本地域名解析服务器就在本地区。
顶级 DNS 服务器，例子：.com，.cn 等。

DNS 使用 TCP、UDP 的情况

DNS 既使用 TCP，也使用 UDP。 DNS 在区域传输的时候使用 TCP 协议，普通的查询使用 UDP 协议。
首先为什么普通的查询使用 UDP 协议？

TCP 需要建立连接，冷门网站建立和删除连接过程花销大。
TCP 报文长。
UDP 相较于 TCP，不用三次握手，DNS 服务器负载低，响应快。

区域传输是什么？
DNS 的规范规定了 2 种类型的 DNS 服务器，一个叫主 DNS 服务器，一个叫辅助 DNS 服务器。在一个区中主 DNS 服务器从自己本机的数据文件中读取该区的 DNS 数据信息，而辅助 DNS 服务器则从区的主 DNS 服务器中读取该区的 DNS 数据信息。当一个辅助 DNS 服务器启动时，它需要与主 DNS 服务器通信，并加载数据信息，这就叫做区传送（zone transfer）。
为什么区域传输使用 TCP 连接
区域传输是 DNS 的事务，准确度高，要求可靠；内容多，数据量大，需要 TCP。

域名劫持和域名投毒是什么

域名劫持是互联网攻击的一种方式，通过伪造域名解析服务器（DNS）的方法，把目标网站域名解析到错误的 IP 地址从而实现用户无法访问目标网站的目的或者蓄意或恶意要求用户访问指定 IP 地址（网站）的目的。
域名投毒 是 DNS 服务器缓存中的记录被修改（所谓被“投毒”），比如用户本来想访问 http://www.baidu.com .com，如果本机没有缓存，就会向本地 DNS 查询该域名的 IP，但由于 DNS 服务器被投毒，所以用户得到的 IP 并不是想要去的地方，而是一个攻击者设定的 IP，这样，用户就被牵引到完全可能是恶意的网站。

TCP 和 UDP

UDP、TCP 的区别、应用场景

	TCP	UDP
可靠性	可靠	不可靠
连接性	面向连接	无连接
双工性	全双工	一/多. 对. 一/多
传输形式	字节流	数据报文段
传输效率	低	高
传输速度	慢	快
所需资源	多	少
首部字节	20-60	8
应用场景	效率要求低，准确性要求高 or 要求有连接的场景	效率要求高，准确性要求低
其他特点	滑动窗口、拥塞控制

UDP 在传送数据之前不需要先建立连接，远端主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频、直播等等

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

img|500

如何实现 UDP 的可靠传输

由于在传输层 UDP 已经是不可靠的连接，那就要在应用层自己实现一些保障可靠传输的机制。

添加序列号
确认机制和超时重传
滑动窗口的流量控制
拥塞控制
等于说要在传输层的上一层（或者直接在应用层）实现 TCP 协议的可靠数据传输机制，比如使用 UDP 数据包+序列号，UDP 数据包+时间戳等方法。
参考连接：如何实现可靠性的 UDP 协议（三大方式 RUDP、RTP、UDT） | 码农家园

TCP 三次握手、四次挥手的详细过程

注意图中的状态！！
三次握手|800
四次挥手|800

第三次挥手：FIN=1，ACK=1

第 2 次握手传回了 ACK，为什么还要传回 SYN？

接收端传回发送端所发送的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传 SYN 则是为了建立并确认从服务端到客户端的通信。”

能不能两/四次握手，三次挥手

为什么要三次握手
三次握手最主要的目的就是
(1) 双方确认自己与对方的发送与接收是正常的
第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常。让客户端知道自己发送的消息服务端知道。
第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常。让服务端知道自己发送的消息客户端能知道。
所以三次握手就能确认双发收发功能都正常，缺一不可。
(2) 告知对方自己的初始序列号，并确认收到对方的序列号
(3) 防止过期的连接请求报文突然送到服务器，使得服务器一直等待连接建立

在双方两次握手即可建立连接的情况下，假设客户端发送 A 报文段请求建立连接，由于网络原因造成 A 暂时无法到达服务器，服务器接收不到请求报文段就不会返回确认报文段。
客户端在长时间得不到应答的情况下重新发送请求报文段 B，这次 B 顺利到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，客户端在收到确认报文后也进入 ESTABLISHED 状态，双方建立连接并传输数据，之后正常断开连接。
此时姗姗来迟的 A 报文段才到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，但是已经进入 CLOSED 状态的客户端无法再接受确认报文段，更无法进入 ESTABLISHED 状态，这将导致服务器长时间单方面等待，造成资源浪费。

为什么不四次握手，防止第三次握手失败
第三次握手失败的话，服务器会在超时后重新进行第二次握手。

为什么要四次挥手
任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。
举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

三次握手阶段，最后一次 ACK 丢失，会发生什么？

服务端：

超时后重传请求，以便客户端第三次握手。
超过指定重试次数，则服务端关闭该连接。

客户端：

客户端认为已经建立连接，发送数据。这时会收到服务端的 RST 报文。客户端知道连接建立失败。

什么是 TIME_WAIT 状态，为什么要有这个状态

TIME_WAIT 状态就是四次挥手中的状态，在这个状态，客户端连接要等待一段长为 2MSL 的时间，才能完全关闭。MSL 是 TCP 报文段在网络中的最大生存时间。

TIMW_WAIT 是主动断开连接的一方会进入的状态，一般来说都是客户端主动断开连接，所以一般都是客户端处于 TIME_WAIT 状态。

可靠的终止 TCP 连接。
防止已失效的连接请求报文段出现在后续的连接阶段。
保证让迟来的 TCP 报文有足够的时间被识别并丢弃。
对于第一点，如果过早断开，服务端的 FIN 没有收到回复，就无法正常的关闭。
对于第二点，如果过早断开，当基于相同插口建立一个新的 TCP 连接，那么迟来的 TCP 报文就被认为是新连接的报文，从而导致数据错乱。

服务器存在大量 TIME_WAIT 或 CLOSE_WAIT 是因为什么，怎么解决

存在大量 TIME_WAIT 原因：高并发情况下，TCP 连接释放时，需要经过 2MSL 的时间之后，才会彻底关闭回收资源。
TIME_WAIT 过多的后果： 服务端出现，消耗服务端资源；客户端出现，客户端无法建立新的连接。
TIME_WAIT 的解决：

快速回收和重用。通过更改系统内核设置，让服务器能够快速回收和重用那些 TIME_WAIT 的资源。
强制关闭。发送 RST 报文强制关闭连接。
服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT 状态，此套接字选项告诉内核，即使此端口正忙（处于 TIME_WAIT 状态），也请继续并重用它。

存在大量 CLOSE_WAIT 原因：在对方关闭连接之后服务器程序自己没有进一步发出 ACK 信号。可能是，对方连接关闭后，程序未检测到；或者程序忘记需要去发送 ACK 信号来关闭连接。
CLOSE_WAIT 的解决：查找代码，看看哪里出现的问题。

什么是 SYN 攻击

攻击者向目标服务器发送大量 SYN 数据包，通常会使用欺骗性的 IP 地址。
然后，服务器响应每个连接请求，并留下开放端口准备好接收响应。
当服务器等待从未到达的最终 ACK 数据包时，攻击者继续发送更多的 SYN 数据包。每个新的 SYN 数据包的到达导致服务器暂时维持新的开放端口连接一段时间，一旦所有可用端口被使用，服务器就无法正常工作。

当出现大量的半连接状态，特别源 IP 地址是随机的，基本上可以断定是一次 SYN 攻击。

防范：

通过防火墙、路由器等过滤网关防护。
通过加固 TCP/IP 协议栈防护，如增加半连接数、缩短超时时间。
SYN cookies 技术。该技术对三次握手做一些修改，专门防范 SYN 攻击的一种手段。服务器进行第 2 次握手，回复 SYN 和 ACK，同时丢弃 SYN 队列条目。如果服务器收到第 3 次握手了，那么会使用编码在 TCP 中的信息重构 SYN 队列条目。

TCP 协议如何保证可靠传输

分割、编号、排序。应用数据被分割成 TCP 认为最适合发送的数据块，TCP 给发送的每一个包进行编号，接收方对数据包进行排序，按顺序将数据传送给应用层。
校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
TCP 的接收端会丢弃重复的数据。
流量控制： TCP 利用滑动窗口实现流量控制。TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。
拥塞控制： 当网络拥塞时，减少数据的发送。
ARQ 协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。即确认应答。
超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

ARQ 协议的作用、简要原理

ARQ 协议，即自动重传请求，使用了确认和超时两个机制来实现可靠的信息传输。发送方接受到 ACK 后，发送后续数据；没有接受到，则重新发送当前数据。
主要应用于数据链路层和传输层。包含停止等待 ARQ 和连续 ARQ 协议。
停止等待 ARQ 协议
发送方：每发送一个分组，就停止等待，直到分组的 ACK 到达再发送下一个分组；如果一段时间没有到达，则重新发送。
接收方：接受到分组后，发送 ACK；如果收到重复的分组，丢弃该分组并且发送 ACK。
特点：简单，效率低，等待时间长。
确认丢失：A 给 B 发送，B 的 ACK 丢失；A 超时重发，B 收到重复的，丢弃并重发 ACK。
确认迟到：A 给 B 发送，B 的 ACK 速度慢；A 超时重发，B 收到重复的，丢弃并重发 ACK；A 收到 B 的 ACK，发送其他数据；A 收到 B 的重复的第二个 ACK，直接丢弃。
连续 ARQ 协议
发送方维持一个窗口，一次发送一整个窗口大小的数据；接收方收到后采用累计确认，对连续的最后一个分组发送确认，表明之前的分组都接受到；发送方根据确认移动窗口位置，然后继续发送窗口大小的数据。
特点：信道利用率高，容易实现；但是，如果 5 个数据，丢失了第 3 个数据，那么只会返回第 2 个数据的确认，发送方需要重新发送 3-5 的数据。

拥塞控制 vs 流量控制

前者，网络中路由器或线路的速度。后者，点对点的速度，抑制发送方的速度。

TCP 的流量控制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

TCP 的拥塞控制

为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口 (cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP 的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

慢开始： 慢开始算法的思路是当主机开始发送数据时，刚开始 cwnd 大小为 1，每经过一个传播轮次，cwnd 加倍。(以字节为单位)
拥塞避免： 当拥塞窗口达到慢开始门限 ssthresh 时，开始拥塞避免；每经过一个往返时间 RTT 就把发送方的 cwnd 加 1.

快重传： 当接收方收到一个错误顺序的报文段后，即中间出现丢包，就立刻发送上一个序列的重复确认；发送方连续收到 3 个重复确认后，就认定后续的数据丢失，立即重传数据，不再等待超时到期。
快恢复： 当出现丢包时，慢开始门限 ssthresh 和拥塞窗口 cwnd 都更新为拥塞窗口的一半，然后开始拥塞避免算法。

TCP 和 UDP 的首部结构

TCP 首部：

源端口、目的端口
序列号、确认号
首部长度、ACK、SYN、RST、FIN、窗口大小
校验和
…

UDP 首部：
源端口、目的端口、长度、校验和。各 2 个字节。

TCP 和 UDP 的校验和如何计算

IP，TCP，UDP，ICMP 校验和的区别和计算_DB_water 的博客-CSDN 博客

TCP 粘包的概念、原因、是否处理、如何处理、UDP 粘包

TCP 粘包概念：发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。
TCP 粘包原因：

TCP 传输特性：
TCP 是数据流的传输，每个 TCP 数据之间没有明确的数据界限，导致无法分清。
发送方粘包问题
TCP 默认使用 Nagle 算法（主要作用：减少网络中报文段的数量），而 Nagle 算法主要做两件事：只有上一个分组得到确认，才会发送下一个分组；收集多个小分组，在一个确认到来时一起发送。
接收方原因
TCP 接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP 将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果 TCP 接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

什么时候需要处理粘包现象
如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象
如果多个分组毫不相干，甚至是并列关系，那么这个时候就一定要处理粘包现象了

如何处理粘包现象

发送方
对于发送方造成的粘包问题，可以通过关闭 Nagle 算法来解决，使用 TCP_NODELAY 选项来关闭算法。
接收方
接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。
应用层
应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。
解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？
格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。
发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前 4 位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

UDP 会不会产生粘包问题呢？
TCP 采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的。
（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。
UDP 则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

TCP 延迟确认应答、捎带应答

延迟确认：TCP 在接收到对端的报文后，并不会立即发送 ack，而是等待一段时间发送 ack，使得返回的窗口增大。一般最多每隔 2 个包或者每隔 200ms 延迟确认。
窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。
捎带应答：延迟确认的基础上，将 ack 和要发送的数据一块发送。

TCP 缓冲区

每个 socket 被创建后，都会分配两个缓冲区，输入缓冲区和输出缓冲区。
TCP 的发送缓冲区是用来缓存应用程序的数据，发送缓冲区的每个字节都有序列号，被应答确认的序列号对应的数据会从发送缓冲区删除掉。

TCP 的 reset 报文

TCP 异常终止 (reset 报文)
TCP 异常终止是相对于正常释放 TCP 链接来说的。一般来说 TCP 四次挥手来释放连接。但是有时可能出现异常情况导致 TCP 没有按照正常的情况释放连接。如果不使用其他方式释放连接，则连接一直存在，占用资源。因此需要一种异常情况下释放连接的方式，即 TCP 的 reset 报文。reset 报文是将 TCP 报文的标志字段中的 reset/RST 位置置为 1 的报文。TCP 处理程序会在自己认为的异常时刻发送 RST 包。

发送 RST 包关闭连接时，不必等缓冲区的包都发出去（不像上面的 FIN 包），直接就丢弃缓存区的包发送 RST 包。而接收端收到 RST 包后，也不必发送 ACK 包来确认。

出现情况

客户端尝试与服务端未开放端口建立 TCP 联系
交互时某一方出现异常，该方发送 reset 报文
接收方收到 TCP 报文不在已建立连接的 TCP 列表中，则发送 reset 报文。
未收到 ACK 报文，且超出一定重传次数或事件后，发送 reset 报文。

IP 协议

IP 地址的分类 A/B/C/D 类指的是什么？什么是子网掩码

子网掩码，用于指示 IP 地址的哪些位标识主机所在的子网，哪些位标识为主机的位掩码。
子网掩码不能单独存在，必须与 IP 地址一起使用。 子网掩码仅具有一项功能，即将 IP 地址分为两部分，即网络地址和主机地址。
全 0 和全 1 的都保留不用。

IPv4 和 IPv6 的区别，IPv6 的改进有哪些

更大的地址空间 IPv4 的地址长度为 32 位，IPv6 的地址长度为 128 位。
报文头简化 IPv4 报头格式中一些冗余的域或被丢弃或被列为扩展报头，从而降低了包处理和报头带宽的开销。
对可选项更大的支持 IPv6 的可选项不放入报头，而是放在一个个独立的扩展头部。如果不指定路由器不会打开处理扩展头部. 这大大改变了路由性能。IPv6 放宽了对可选项长度的严格要求 (IPv4 的可选项总长最多为 40 字节)，并可根据需要随时引入新选项。
更高的安全性 对网络层数据进行加密。

其他

URI 和 URL 的区别是什么?

URI (Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL (Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。
URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

负载均衡的算法

多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，能互相分担负载。

轮询法: 将请求按照顺序轮流的分配到服务器上。大锅饭，不能发挥某些高性能服务器的优势。
随机法: 随机获取一台，和轮询类似。
哈希法: 通过 ip 地址哈希化来确定要选择的服务器编号。好处是, 每次客户端访问的服务器都是同一个服务器，能很好地利用 session 或者 cookie。
加权轮询: 根据服务器性能不同加权。

浏览器中输入一个 URL 并回车会发生什么

在浏览器输入 URL 回车之后发生了什么（超详细版） - 知乎

URL 解析
DNS 查询
TCP 连接
- HTTP 数据、TCP 首部、IP 首部、以太网首部
发送 HTTP 请求
服务器处理请求并返回 HTTP 报文
- 主进程监听、创建子进程处理、解析数据、是否重定向、返回资源、解释器、返回响应
浏览器解析渲染页面
连接结束

打开一个网页，整个过程会使用哪些协议？
.aliyuncs.com/2019-11/url 输入到展示出来的过程.jpg” style=“zoom:50%; ” />
上图有一个错误，请注意，是 OSPF 不是 OPSF。 OSPF（Open Shortest Path First，ospf）开放最短路径优先协议, 是由 Internet 工程任务组开发的路由选择协议
具体可以参考下面这篇文章：

https://segmentfault.com/a/1190000006879700

推荐大家看一下《图解 HTTP》这本书，这本书页数不多，但是内容很是充实，不管是用来系统的掌握网络方面的一些知识还是说纯粹为了应付面试都有很大帮助。下面的一些文章只是参考。大二学习这门课程的时候，我们使用的教材是《计算机网络第七版》（谢希仁编著），不推荐大家看这本教材，书非常厚而且知识偏理论，不确定大家能不能心平气和的读完。

🪴 Obsidian Publish

探索