计算机网络分层

图片说明

应用层：网络服务与最终用户的一个接口。协议：HTTP、HTTPS、FTP、DNS。
表示层：数据的表示、安全、压缩。ASCII等。
会话层：建立、管理、终止会话等。
传输层：为进程提供通用数据传输服务。
网络层：进行逻辑地址寻址，实现不同网络之间的路径选择。路由器所在。因为IP协议在网络层，通过数据包中的IP地址进行转发。
数据链路层：建立逻辑连接、进行硬件地址寻址、差错校验等功能。交换机所在。因为交换机要处理帧，通过帧中的MAC地址进行转发。
物理层：建立、维护、断开物理连接。集线器所在。

TCP 和 UDP 的区别

  • 用户数据报协议 UDP：
    是无连接的；
    没有拥塞控制；
    数据单位为用户数据报；
    面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部）；
    支持一对一，一对多，多对一，多对多的交互通信。

  • 传输控制协议 TCP：
    是面向连接的；
    有流量控制，拥塞控制；
    数据单位为报文段；
    面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块）；
    每条TCP的连接只能是一对一。

所以如果我们的发送消息、浏览网页之类的场景，因为要确保用户消息不丢失，要使用 TCP 协议。
如果是在视频聊条或看直播，那可以用 UDP 协议，因为即时几个画面丢失，对用户来说影响也不大。

TCP 头部结构

图片说明

包括：源地址和目的地址、序列号、确认序列号、窗口大小、校验和、数据

  • 16位端口号：
    表示该报文段来自哪里（源端口）以及要传给哪个上层协议或应用程序（目的端口）。

  • 32位序号：
    表示一次 TCP 通信过程（从建立连接到断开）过程中某一次传输方向上的字节流的每个字节的编号。假定主机 A 和 B 进行 TCP 通信， A 传送给 B 一个 TCP 报文段中，序号值被系统初始化为某一个随机值 ISN，那么在该传输方向上（从 A 到 B），后续的所有 TCP 报文段中的序号值都会被设定为 ISN 加上该报文段所携带数据的第一个字节在整个字节流中的偏移。例如某个 TCP 报文段传送的数据是字节流中的第 1025~2048 字节，那么该报文段的序号值就是 ISN+1025.

  • 32位确认号：
    用作对另一方发送的 TCP 报文段的响应，其值是收到对方的 TCP 报文段的序号值 +1。假定主机 A 和 B 进行 TCP 通信，那么 A 发出的 TCP 报文段不但带有自己的序号，也包含了对 B 发送来的 TCP 报文段的确认号。反之也一样。

  • 4位头部长度：
    表示 TCP 头部有多少个32bit字（4字节），因为4位最大值是15，所以最多有15个32bit，也就是60个字节是最大的 TCP 头部长度。

  • 6位标志位：
    URG：紧急指针是否有效
    ACK：表示确认呢是否有效，携带 ACK 标志的报文段也称确认报文段
    PSH：提示接收端应用程序应该立即从 TCP 接受缓冲区中读走数据，为后续接收的数据让出空间
    RST：表示要求对方重建连接。带 RST 标志的 TCP 报文段也叫复位报文段
    SYN：表示建立一个连接，携带 SYN 的 TCP 报文段为同步报文段

  • 16位窗口大小：
    是 TCP 流量控制的一个手段，这里说的窗口是指接收通告窗口，它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。

  • 16位校验和：
    由发送端填充，接收端对 TCP 报文段执行 CRC 算法以检验 TCP 报文段在传输过程中是否破坏。注意这个校验不仅包括 TCP 头部，也包括数据部分。这也是 TCP 可靠传输的一个重要保障。

  • 16位紧急指针：
    是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一个字节的序号。因此这个字段是紧急指针相对当前序号的偏移量，发送紧急数据时会用这个。

  • TCP 头部选项：
    最后一个选线字段是可变长的可选信息，最多包含40字节的数据。

IP 头部结构

图片说明

IP 为上层协议提供无状态、无连接、不可靠的服务。

  • 4位版本号：
    IP协议（IPv4）版本号位4

  • 4位头部长度：
    表示头部有多少个4字节，即最大共 15*4 字节

  • 8位服务类型：
    包含一个4位优先权字段：最小延迟，最大吞吐量，最高可靠性和最小费用。

  • 16位总长度：
    表示整个IP数据报的的长度，最大表示 65535，但由于 MTU 限制，一般无法到达这个值

  • 16位标识：
    唯一的标识数据报。系统采用加1的方式边发送边赋值。

  • 3位标识（保留，DF 禁止分片，MF 更多分片）：
    所以这个标志是为分片存在，DF 设置时禁止分片所以如果数据报太大则发送失败。MF 设置时，如果产生分片，除了最后一个分片，其他分片置1.

  • 13位分片偏移：
    分片相对原始 IP 数据报开始处的偏移。

  • 8位生存时间（TTL）：
    数据报到达目的地之前允许经过的路由跳跳数。跳一下减1，为0时丢弃。

  • 8位协议：
    用来区分上层协议（ICMP 为1，TCP 为6，UDP 为17）.

  • 16位头部校验和：
    仅以 CRC 算法检验数据报头部在传输过程中是否损坏。

  • 32位源端口 IP 地址和目的端口地址：

  • 选项（可变长）：
    记录路由，告诉途径的所有路由把 IP 填进来。时间戳，告诉每个路由器都将数据报被转发的时间传进来。松散路由选择，指定一个路由器 IP 地址列表，必须按这个表发送，严格路由选择，数据报经过路由表。

TCP 三次握手、四次挥手：

第一次握手：

主机 A 发送标志位 SYN = 1，客户端随机产生一个起始序号 seq = x 的数据包到服务器（连接请求报文不携带数据，但要消耗掉一个序号），客户端进程进入 SYN_SENT（同步发送）状态。主机 B 由 SYN=1 知道， A 要求建立联机；

第二次握手：

主机 B 收到请求后要确认联机信息，向 A 发送 确认号字段的值为ack number=（主机 A 的 seq + 1），标志位 SYN=1，ACK=1，服务端随机产生起始序号 seq=y 的包（确认报文不携带数据，但也要消耗掉一个序号）。服务端进入 SYN_RCVD（同步接收）状态；

  • 服务端的资源是在完成第二次握手时开始分配的，所以服务端易于受到 SYN 洪泛攻击。

第三次握手：

主机 A 收到后检查 确认号字段的值（ack number） 是否正确，即第一次发送的 seq number+1，以及位码 ACK 是否为1，若正确，主机 A 会再发送 seq number、ack number=(主机 B 的seq+1) 和 ACK=1，主机 B 收到后确认 seq 值与 ACK=1 则连接建立成功。完成三次握手，进入 ESTABLISHED（建立连接）状态，主机 A 与主机 B 开始传送数据。

图片说明

为什么要三次握手？

主要为了防止已失效的连接请求报文段突然又传送到了 B，因而产生错误。如 A 发出连接请求，但因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接， A 共发出了两个连接请求报文段，其中第一个丢失，第二个到达了 B，但是第一个丢失的报文段只是在某些网络节点长时间滞留了，延误到连接释放以后的某个时间才到达 B，此时 B 误以为 A 又发出一次新的连接请求，于是就向 A 发出确认报文段，同意建立连接，不采用三次握手，只要 B 发出确认，就建立新的连接了，此时 A 不理睬 B 的确认且不发送数据，则 B 一致等待 A 发送数据，浪费资源。

图片说明

为什么要四次挥手？

因为当 服务端收到 客户端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。但是关闭连接时，当 服务端收到 FIN 报文时，很可能并不会立即关闭 socket，所以只能先回复一个 ACK 报文，告诉 客户端，“你发的 FIN 报文我收到了”。只有等到我 服务端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。故需要四步握手。
客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器就会发送 FIN 连接释放报文。

简述 TIME_WAIT 和 CLOSE-WAIT

TIME_WAIT（主动关闭连接）

客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：

  • 一是确保最后一个确认报文能够到达。如果服务端没收到客户端发送来的确认报文，那么就会重新发送连接释放请求报文，客户端等待一段时间就是为了处理这种情况发生。
  • 二是等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

CLOSE_WAIT（被动关闭连接）

服务器端收到客户端发送的 FIN，则按照 TCP 实现发送 ACK，因此进入 CLOSE_WAIT 状态。但如果服务端不执行 close()，就不能由 CLOSE_WAIT 迁移到 LAST_ACK，则系统中会存在很多 CLOSE_WAIT 状态的连接。

TCP 通信过程中 time_wait 和 close_wait 产生过多的原因和解决。

TCP 协议如何保证传输可靠性

主要方式有：

  • 校验和

  • 确认应答与序列号

  • 超时重传
    简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到 ACK 报文，那么对刚才发送的数据进行重新发送。

  • 连接管理
    三次握手和四次挥手

  • 流量控制
    TCP 根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。TCP 协议的报头信息当中，有一个 16 位字段的窗口大小，发送方根据 ACK 报文里的窗口大小的值的改变进而改变自己的发送速度。
    （滑动窗口）

  • 拥塞控制
    慢开始、拥塞避免、快重传、快恢复
    （1）慢开始的算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。
    （2）拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。
    （3）快重传和快恢复：发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。即连续收到三个重复的确认转入拥塞避免。

DNS 域名解析

  • DNS 占用 53号端口，同时使用 TCP 和 UDP 协议

  • DNS 区域传输的时候使用 TCP 协议：
    （1）辅域名服务器会定时（一般 3 小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用 TCP 而不是 UDP，因为数据同步传送的数量比一个请求应答的数据要多得多。
    （2）TCP 是一种可靠连接，保证了数据的准确性。

  • 域名解析时使用 UDP 协议：
    客户端向 DNS 服务器查询域名，一般返回的内容都不超过 512 字节，用 UDP 传输即可。不用经过三次握手，这样 DNS 服务器负载更低，响应更快。理论上说，客户端也可以指定向 DNS 服务器查询时用 TCP，但事实上，很多 DNS 服务器进行配置的时候，仅支持 UDP 查询包。

HTTP 报文结构和状态码

  • 请求格式
    请求行、请求头、空行、请求数据
    图片说明

  • 返回格式（状态码）
    状态行、消息报文、响应正文
    图片说明
    常用状态（牢记）：
    200 OK：客户端请求成功。
    301 Moved Permanently：永久性重定向。
    302 Found：临时性重定向。
    400 Bad Request：客户端请求有语法错误，不能被服务端所理解。
    401 Unauthorized：请求未经授权，这个状态代码必须和 WWW-Authenticate 报头域一起使用。
    403 Forbidden：服务器收到请求，但是拒绝提供服务。
    404 Not Found：请求资源不存在，举个例子：输入了错误的 URL。
    500 Internal Server Error：服务器发生不可预期的错误。
    504 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常，举个例子：HTTP/1.1 200 OK（CRLF）

  • HTTP/1.1 的新特性。默认是长连接
    支持流水线
    支持同时打开多个 TCP 连接
    新增状态码 100：目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。
    支持分块传输编码：可以把数据分割成多块，让浏览器逐步显示页面。
    新增缓存处理指令 max-age：有效期来指定 cookie 的持久性问题。

  • 缓存问题

GET 和 POST 比较

  • 作用：
    GET 用于获取资源。
    POST 用于传输实体主体。

  • 参数：
    GET 和 POST 的请求都能使用额外的参数，
    但是 GET 的参数是以查询字符串出现在 URL 中，
    而 POST 的参数存储在实体主体中。

  • 修改性：
    HTTP 方法不会改变服务器状态，GET 方法是安全的，而 POST 却不是，因为 POST 的目的是传送实体主体内容。这个内容可能是用户上传的表单数据，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。

  • 幂等性：
    GET/pageX HTTP/1.1 是幂等的，连续调用多次，客户端接收到的结果都是一样的；
    POST/add_row HTTP/1.1 不是幂等的，如果调用多次，就会增加多行记录；

  • 可缓存：
    GET 可缓存（响应状态码和Cache-Control保证是可缓存）；
    POST 不可缓存。

  • 底层：
    对于 GET 方式的请求，浏览器会把 HTTP header 和 data 一并发送出去，服务器响应 200 ok（返回数据）；
    对于 POST 方式的请求，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

Cookie 作用、安全性问题和 Session 的比较。

（1）Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一个服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。可用作会话状态管理（如用户登录状态、购物车、游戏分数或其他需要记录的信息）、个性化设置（如用户自定义设置、主题等）、浏览器行为跟踪（如跟踪分析用户行为等）。可能被浏览器禁用。

（2）Session 存储在服务器端，存储在服务器端的信息更加安全。
使用 Session 维护用户登录状态的过程如下：（需要 cookie 作为传输机制）
用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID：
服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

（3）二者区别
Cookie 只能存储 ASCII 码字符串，而 Session 则可以存取任何类型的数据，因此在考虑数据复杂性时首选 Session；
Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；
对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。

  • 存在的位置
    都是会话技术
    Cookie 存在于客户端，临时文件夹。
    Session 存在服务器端。

  • 安全性
    Cookie 有安全隐患，通过拦截或者本地文件得到你的 Cookie 进行攻击。
    Session 相对比较安全。

  • 大小限制
    Cookie 有大小限制，单个不超过 4K，浏览器中 Cookie 个数也有限制。
    Session 没有大小限制，是和服务器内存有关。

  • 生命周期
    Cookie 生命周期可以设置，默认是一次会话的时间。
    Session 生命周期是间隔的，关闭服务器会造成周期结束。

短连接和长连接、流水线

  • 短连接和长连接
    当浏览器访问一个包含多张图片的 HTML 页面时，除了请求访问 HTML 页面资源，还会请求图片资源。如果每进行一次 HTTP 通信就要新建一个 TCP 连接，那么开销会很大。
    长连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信。
    从 HTTP/1.1 开始默认是长连接的，如果要断开连接，需要由客户端或者服务端提出断开，使用 Connection:close；
    在 HTTP/1.1 之前默认是短连接的，如果需要使用长连接，则使用 Connection:Keep-Alive。

  • 流水线
    默认情况下，HTTP 请求是按顺序发出的，下一个请求只有在当前请求收到响应后才会被发出。由于会受到网络延迟和带宽的限制，在下一个请求被发送到服务端之前，可能需要等待很长时间。
    流水线是在同一条长连接上发出连续的请求，而不用等待响应返回，这样可以避免连接延迟。

HTTP 的安全性问题

  • 安全问题
    使用明文进行通信，内容可能会被窃听；
    不验证通信方的身份，通信方的身份有可能遭遇伪装；
    无法证明报文的完整性，报文有可能遭篡改。

  • HTTPS 加密
    通过利用 SSL，HTTPS 具有加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。
    HTTPS 采用混合的加密机制，使用非对称加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。
    HTTPS 加密的过程：
    （1）客户使用 HTTPS 的 URL 访问 Web 服务器，要求与 Web 服务器建立 SSL 连接。
    （2）Web 服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
    （3）客户端的浏览器与 Web 服务器开始协商 SSL 连接的安全等级，也就是信息加密的等级。
    （4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
    （5）Web 服务器利用自己的私钥解密出会话密钥。
    （6）Web 服务器利用会话密钥加密与客户端之间的通信。

缺点：
因为需要进行加密解密等过程，因此速度会更慢；
需要支付证书授权的高额费用。

HTTP 与 FTP 的异同点

  • 同：
    （1）都是应用层协议；
    （2）都运行在 TCP 上，即都使用 TCP（而不是 UDP）作为其支撑的运输层协议。

  • 异：
    （1）HTTP 是超文本传输协议，是面向网页的；FTP 是文件传输协议，是面向文件的。
    （2）HTTP 的控制信息是带内（in-bland）传输的；FTP 的控制信息是带外（out-of-band）传输的。
    （3）HTTP 是无状态的；FTP 服务器必须在整个会话期间保留用户的状态（state）信息。
    （4）FTP 使用两个并行的 TCP 连接来传输文件，一个是控制连接，一个是数据连接。FTP 的控制连接是持久连接，数据连接是非持久连接；而 HTTP 既可以使用非持久连接，也可以使用持久连接。

  • 带内传输：管理控制信息与数据信息使用统一物理通道进行传送。当网络出现故障中断时数据传输和管理都无法正常进行。

  • 带外传输：在于通过不同的物理通道传送管理控制信息和数据信息，两者完全独立，互不影响。

输入网址发生了什么？

  • 第一步：浏览器查找该域名的 IP 地址
    （DNS 域名解析，浏览器缓存，系统缓存，路由器缓存，ISP DNS 服务器，根域名服务器）
    如果用到 CDN 内容分发网络，本质是在现有网络结构中增加了一层（客户端+CDN+服务器），CDN 包括高速缓存和整体负载均衡（GSLB），主要缓存静态资源。理解：当发送一个网址时，先去 DNS 域名解析到 CDN 负载均衡系统，然后把响应最快的 IP 缓存节点服务器（第一次访问，得向源服务器请求内容，进行缓存）返回给用户。

  • 第二步：浏览器根据解析得到的 IP 地址向 web 服务器发送一个 HTTP 请求
    （就是建立 Socket 通信的过程。HTTP 请求的协议：请求行、请求头、请求体，状态码）

  • 第三步：服务器收到请求并进行处理
    （负载均衡：对工作任务进行平衡，如图片服务器、应用服务器、分为链路负载均衡，集群负载均衡，操作系统负载均衡）反向代理

  • 第四步：服务器返回一个响应（响应状态码）

  • 第五步：浏览器对该响应进行解码，渲染显示。

  • 第六步：页面显示完成后，浏览器发送异步请求。
    （持续更新一些页面信息）