计算机网络

计算机网络

Socket 模型

socket通信模型_socket模型_骚火棍的博客-CSDN博客

连接建立

socket模型可以用于发送TCP和UDP协议的数据。

在socket编程中，可以使用socket接口创建一个套接字，并指定套接字的类型为流套接字（SOCK_STREAM）或数据报套接字（SOCK_DGRAM）。

  • TCP（传输控制协议）是一种面向连接的、可靠的、基于字节流的传输协议。在socket编程中，使用流套接字（SOCK_STREAM）来发送TCP数据。通过TCP套接字，应用程序可以建立连接、进行可靠的数据传输，确保数据的顺序和完整性。

  • UDP（用户数据报协议）是一种无连接的、不可靠的、基于数据报的传输协议。在socket编程中，使用数据报套接字（SOCK_DGRAM）来发送UDP数据。通过UDP套接字，应用程序可以以无连接的方式发送数据，但无法保证数据的可靠性和顺序。

无论是TCP还是UDP，socket模型提供了一种通用的编程接口，使应用程序能够方便地发送和接收数据。通过socket接口提供的函数，应用程序可以创建套接字、指定协议类型（TCP或UDP）、设置套接字选项、进行数据的发送和接收等操作。这样，应用程序可以根据需要选择使用TCP或UDP协议进行数据的传输。

在这里插入图片描述

sk_buf数据封装

数据封装

为了在层级之间传递数据时，不发生拷贝，只用 sk_buff 一个结构体来描述所有的网络包

img

发送网络数据的时候，涉及几次内存拷贝操作？

第一次，调用发送数据的系统调用的时候，内核会申请一个内核态的 sk_buff 内存，将用户待发送的数据拷贝到 sk_buff 内存，并将其加入到发送缓冲区。

第二次，在使用 TCP 传输协议的情况下，从传输层进入网络层的时候，每一个 sk_buff 都会被克隆一个新的副本出来。副本 sk_buff 会被送往网络层，等它发送完的时候就会释放掉，然后原始的 sk_buff 还保留在传输层，目的是为了实现 TCP 的可靠传输，等收到这个数据包的 ACK 时，才会释放原始的 sk_buff 。

第三次，当 IP 层发现 sk_buff 大于 MTU 时才需要进行。会再申请额外的 sk_buff，并将原来的 sk_buff 拷贝为多个小的 sk_buff。

Socket 结构体

文件描述符的作用是什么？每一个进程都有一个数据结构 task_struct，该结构体里有一个指向「文件描述符数组」的成员指针。该数组里列出这个进程打开的所有文件的文件描述符。数组的下标是文件描述符，是一个整数，而数组的内容是一个指针，指向内核中所有打开的文件的列表，也就是说内核可以通过文件描述符找到对应打开的文件。

然后每个文件都有一个 inode，Socket 文件的 inode 指向了内核中的 Socket 结构，在这个结构体里有两个队列，分别是发送队列和接收队列，这个两个队列里面保存的是一个个 struct sk_buff，用链表的组织形式串起来。

sk_buff 可以表示各个层的数据包，在应用层数据包叫 data，在 TCP 层我们称为 segment，在 IP 层我们叫 packet，在数据链路层称为 frame。

你可能会好奇，为什么全部数据包只用一个结构体来描述呢？协议栈采用的是分层结构，上层向下层传递数据时需要增加包头，下层向上层数据时又需要去掉包头，如果每一层都用一个结构体，那在层之间传递数据的时候，就要发生多次拷贝，这将大大降低 CPU 效率。

于是，为了在层级之间传递数据时，不发生拷贝，只用 sk_buff 一个结构体来描述所有的网络包，那它是如何做到的呢？是通过调整 sk_buff 中 data 的指针，比如：

  • 当接收报文时，从网卡驱动开始，通过协议栈层层往上传送数据报，通过增加 skb->data 的值，来逐步剥离协议首部。
  • 当要发送报文时，创建 sk_buff 结构体，数据缓存区的头部预留足够的空间，用来填充各层首部，在经过各下层协议时，通过减少 skb->data 的值来增加协议首部。

你可以从下面这张图看到，当发送报文时，data 指针的移动过程。

img

零拷贝

将磁盘文件通过网络进行传输

0、DMA

减少 cpu 在 IO拷贝上的阻塞时间

之前：

img

DMA技术

img

具体过程：

  • 用户进程调用 read 方法，向操作系统发出 I/O 请求，请求读取数据到自己的内存缓冲区中，进程进入阻塞状态；
  • 操作系统收到请求后，进一步将 I/O 请求发送 DMA，然后让 CPU 执行其他任务；
  • DMA 进一步将 I/O 请求发送给磁盘；
  • 磁盘收到 DMA 的 I/O 请求，把数据从磁盘读取到磁盘控制器的缓冲区中，当磁盘控制器的缓冲区被读满后，向 DMA 发起中断信号，告知自己缓冲区已满；
  • DMA 收到磁盘的信号，将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中，此时不占用 CPU，CPU 可以执行其他任务；
  • 当 DMA 读取了足够多的数据，就会发送中断信号给 CPU；
  • CPU 收到 DMA 的信号，知道数据已经准备好，于是将数据从内核拷贝到用户空间，系统调用返回；

可以看到， CPU 不再参与「将数据从磁盘控制器缓冲区搬运到内核空间」的工作，这部分工作全程由 DMA 完成。但是 CPU 在这个过程中也是必不可少的，因为传输什么数据，从哪里传输到哪里，都需要 CPU 来告诉 DMA 控制器。

早期 DMA 只存在在主板上，如今由于 I/O 设备越来越多，数据传输的需求也不尽相同，所以每个 I/O 设备里面都有自己的 DMA 控制器。

一、read + write

read 读 内核缓冲区 到 用户缓冲区

write 写 用户缓冲区 到 socket 缓冲区

1
2
read(file, tmp_buf, len);
write(socket, tmp_buf, len);

img

还发生了 4 次数据拷贝，其中两次是 DMA 的拷贝，另外两次则是通过 CPU 拷贝的，下面说一下这个过程：

  • 第一次拷贝，把磁盘上的数据拷贝到操作系统内核的缓冲区里，这个拷贝的过程是通过 DMA 搬运的。
  • 第二次拷贝，把内核缓冲区的数据拷贝到用户的缓冲区里，于是我们应用程序就可以使用这部分数据了，这个拷贝到过程是由 CPU 完成的。
  • 第三次拷贝，把刚才拷贝到用户的缓冲区里的数据，再拷贝到内核的 socket 的缓冲区里，这个过程依然还是由 CPU 搬运的。
  • 第四次拷贝，把内核的 socket 缓冲区里的数据，拷贝到网卡的缓冲区里，这个过程又是由 DMA 搬运的。

二、mmap + write

mmap 减少 内核缓冲区 到 用户缓冲区到拷贝

在前面我们知道，read() 系统调用的过程中会把内核缓冲区的数据拷贝到用户的缓冲区里，于是为了减少这一步开销，我们可以用 mmap() 替换 read() 系统调用函数。

1
2
buf = mmap(file, len);
write(sockfd, buf, len);

img

具体过程如下：

  • 应用进程调用了 mmap() 后，DMA 会把磁盘的数据拷贝到内核的缓冲区里。接着，应用进程跟操作系统内核「共享」这个缓冲区；
  • 应用进程再调用 write()，操作系统直接将内核缓冲区的数据拷贝到 socket 缓冲区中，这一切都发生在内核态，由 CPU 来搬运数据；
  • 最后，把内核的 socket 缓冲区里的数据，拷贝到网卡的缓冲区里，这个过程是由 DMA 搬运的。

我们可以得知，通过使用 mmap() 来代替 read()， 可以减少一次数据拷贝的过程。

三、sendfile

直接在内核层面进行 文件从 磁盘 -》 内核缓冲区 -》socket 缓冲区的-》网卡

在 Linux 内核版本 2.1 中，提供了一个专门发送文件的系统调用函数 sendfile()，函数形式如下：

1
2
3
4
#include <sys/socket.h>
// 目的端描述符 源端描述符 偏移量 长度
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
// 它的前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度。

首先，它可以替代前面的 read() 和 write() 这两个系统调用，这样就可以减少一次系统调用，也就减少了 2 次上下文切换的开销。

其次，该系统调用，可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里，不再拷贝到用户态，这样就只有 2 次上下文切换，和 3 次数据拷贝。如下图：

img

但是这还不是真正的零拷贝技术，如果网卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技术（和普通的 DMA 有所不同），我们可以进一步减少通过 CPU 把内核缓冲区里的数据拷贝到 socket 缓冲区的过程。

于是，从 Linux 内核 2.4 版本开始起，对于支持网卡支持 SG-DMA 技术的情况下， sendfile() 系统调用的过程发生了点变化，具体过程如下：

  • 第一步，通过 DMA 将磁盘上的数据拷贝到内核缓冲区里；
  • 第二步，缓冲区描述符和数据长度传到 socket 缓冲区，这样网卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷贝到网卡的缓冲区里，此过程不需要将数据从操作系统内核缓冲区拷贝到 socket 缓冲区中，这样就减少了一次数据拷贝；

所以，这个过程之中，只进行了 2 次数据拷贝，如下图：

img

这就是所谓的零拷贝（*Zero-copy*）技术，因为我们没有在内存层面去拷贝数据，也就是说全程没有通过 CPU 来搬运数据，所有的数据都是通过 DMA 来进行传输的。。

零拷贝技术的文件传输方式相比传统文件传输的方式，减少了 2 次上下文切换和数据拷贝次数，只需要 2 次上下文切换和数据拷贝次数，就可以完成文件的传输，而且 2 次的数据拷贝过程，都不需要通过 CPU，2 次都是由 DMA 来搬运。

所以，总体来看，零拷贝技术可以把文件传输的性能提高至少一倍以上。

协议

MAC 层报文

DNS 解析

img

步骤

第一步、

  本地电脑会检查浏览器缓存中有没有这个域名对应的解析过的IP地址，如果缓存中有，这个解析过程就结束。浏览器缓存域名也是有限制的，不仅浏览器缓存大小有限制，而且缓存的时间也有限制，通常情况下为几分钟到几小时不等，域名被缓存的时间限制可以通过TTL属性来设置。这个缓存时间太长和太短都不太好，如果时间太长，一旦域名被解析到的IP有变化，会导致被客户端缓存的域名无法解析到变化后的IP地址，以致该域名不能正常解析，这段时间内有一部分用户无法访问网站。如果设置时间太短，会导致用户每次访问网站都要重新解析一次域名。

第二步、

    如果浏览器缓存中没有数据，浏览器会查找操作系统缓存中是否有这个域名对应的DNS解析结果。其实操作系统也有一个域名解析的过程，在Linux中可以通过/etc/hosts文件来设置，而在windows中可以通过配置C:\Windows\System32\drivers\etc\hosts文件来设置，用户可以将任何域名解析到任何能够访问的IP地址。例如，我们在测试时可以将一个域名解析到一台测试服务器上，这样不用修改任何代码就能测试到单独服务器上的代码的业务逻辑是否正确。正是因为有这种本地DNS解析的规程，所以有黑客就可能通过修改用户的域名来把特定的域名解析到他指定的IP地址上，导致这些域名被劫持。

第三步、

    前两个过程无法解析时，就要用到我们网络配置中的"DNS服务器地址"了。操作系统会把这个域名发送给这个本地DNS服务器。每个完整的内网通常都会配置本地DNS服务器，例如用户是在学校或工作单位接入互联网，那么用户的本地DNS服务器肯定在学校或工作单位里面。它们一般都会缓存域名解析结果，当然缓存时间是受到域名的失效时间控制的。大约80%的域名解析到这里就结束了，后续的DNS迭代和递归也是由本地DNS服务器负责。

windows在这配置：控制面板-》网络和共享中心-》更改适配器设置-》选中目标适配器右键选择属性-》Internet协议版本4(TCP/IPv4)-》配置DNS地址。

Linux在这设置：/etc/resolv.conf

第四步、

   如果本地DNS服务器仍然没有命中，就直接到根DNS服务器请求解析。

第五步、

   根DNS服务器返回给本地DNS域名服务器一个顶级DNS服务器地址，它是国际顶级域名服务器，如.com、.cn、.org等，全球只有13台左右。

第六步、

   本地DNS服务器再向上一步获得的顶级DNS服务器发送解析请求。

第七步、

    接受请求的顶级DNS服务器查找并返回此域名对应的Name Server域名服务器的地址，这个Name Server服务器就是我要访问的网站域名提供商的服务器，其实该域名的解析任务就是由域名提供商的服务器来完成。   比如我要访问www.baidu.com，而这个域名是从A公司注册获得的，那么A公司上的服务器就会有www.baidu.com的相关信息。

第八步、

   Name Server服务器会查询存储的域名和IP的映射关系表，再把查询出来的域名和IP地址等等信息，连同一个TTL值返回给本地DNS服务器。

第九步、

   返回该域名对应的IP和TTL值，本地DNS服务器会缓存这个域名和IP的对应关系，缓存时间由TTL值控制。

第十步、

   把解析的结果返回给本地电脑，本地电脑根据TTL值缓存在本地系统缓存中，域名解析过程结束在实际的DNS解析过程中，可能还不止这10步，如Name Server可能有很多级，或者有一个GTM来负载均衡控制，这都有可能会影响域名解析过程。

递归查询 和 迭代查询

DNS客户端（本机）和本地名称服务器是递归，而本地名称服务器和其他名称服务器之间是迭代

递归查询和迭代查询是DNS中两种不同的查询方式。

递归查询是指当DNS客户端(主机)向本地名称服务器发送查询请求时，如果本地名称服务器无法直接回答该查询，它会继续向其他名称服务器发送查询请求，直到获得最终的查询结果，并将结果返回给DNS客户端。在递归查询中，本地名称服务器充当了中间人的角色，负责代替DNS客户端进行查询，并返回最终结果。

迭代查询是指DNS客户端自己进行查询，它会向本地名称服务器发送查询请求，如果本地名称服务器无法回答该查询，它会返回一个指向其他名称服务器的引用（即下一级名称服务器的地址），然后DNS客户端会直接向下一级名称服务器发送查询请求，依次迭代进行查询，直到获得最终的查询结果。

在DNS解析过程中，DNS客户端和本地名称服务器之间的查询是递归的，因为本地名称服务器会代替DNS客户端进行查询。而本地名称服务器和其他名称服务器之间的查询是迭代的，因为本地名称服务器会返回一个指向下一级名称服务器的引用，让DNS客户端自己进行查询。

需要注意的是，递归查询和迭代查询并不是互斥的，它们可以在不同的阶段和角色中使用。递归查询通常发生在DNS客户端和本地名称服务器之���，而迭代查询通常发生在本地名称服务器和其他名称服务器之间。

希望以上解释能够帮助您理解递归查询和迭代查询的区别。如果您有更多问题，请随时提问。

容器间的网络

凤凰架构：容器间网络 | 凤凰架构 (icyfenix.cn)

​

基础概念

小林coding – 计算机基础；；小林coding (xiaolincoding.com)

官方文档地址(更加专业的官方介绍) : Web 开发技术 | MDN (mozilla.org)

(12条消息) 计算机网络面试题（超详细整理）_龙源lll的博客-CSDN博客

计算机网络各层涉及协议(超级详细）

模型

七层模型

​ 第七层：应用层 定义了用于在网络中进行通信和数据传输的接口 - 用户程式；提供标准服务，比如虚拟终端、文件以及任务的传输 和处理；

　　第六层：表示层 掩盖不同系统间的数据格式的不同性； 指定独立结构的数据传输格式； 数据的编码和解码；加密和解密；压缩和 解压缩

　　第五层：会话层 管理用户会话和对话； 控制用户间逻辑连接的建立和挂断；报告上一层发生的错误

　　第四层：传输层 管理网络中端到端的信息传送； 通过错误纠正和流控制机制提供可靠且有序的数据包传送； 提供面向无连接的数 据包的传送；

　　第三层：网络层 定义网络设备间如何传输数据； 根据唯一的网络设备地址路由数据包；提供流和拥塞控制以防止网络资源的损耗

　　第二层：数据链路层 定义操作通信连接的程序； 封装数据包为数据帧； 监测和纠正数据包传输错误

　　第一层：物理层 定义通过网络设备发送数据的物理方式； 作为网络媒介和设备间的接口；定义光学、电气以及机械特性。

四层模型

img

TCP状态机

三次握手

SYN ：同步标志

FIN ：终止标志

ACK ： 确认收到信息标志

seq ： 报文段序列号（标记当前 客户端/服务端 报文序列 - 保证有序）— 发送者 发送窗口的第一个字节位置

ack ： 确认收到序列号是否正确 - 确认号。— 发送者 下一个接收数据的 接收窗口位置

在这里插入图片描述

TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了 LISTEN 监听状态

第一次握手 TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT 同步已发送状态

第二次握手 TCP服务器收到请求报文后，如果同意连接，则会向客户端发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了 SYN-RCVD 同步收到状态

第三次握手 TCP客户端收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED == (established == 建立了)已建立连接状态 触发三次握手

有人可能会很疑惑为什么要进行第三次握手？
主要原因：防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误

第一次握手： 客户端向服务器端发送报文
证明客户端的发送能力正常
第二次握手：服务器端接收到报文并向客户端发送报文
证明服务器端的接收能力、发送能力正常
第三次握手：客户端向服务器发送报文
证明客户端的接收能力正常

四次挥手

在这里插入图片描述

第一次挥手 客户端发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态

第二次挥手 服务器端接收到连接释放报文后，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT 关闭等待状态

第三次挥手 客户端接收到服务器端的确认请求后，客户端就会进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文，服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

第四次挥手 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态，但此时TCP连接还未终止，必须要经过2MSL （Maximum Segment lifetime）后（最长报文寿命），当客户端撤销相应的TCB后，客户端才会进入CLOSED关闭状态，服务器端接收到确认报文后，会立即进入CLOSED关闭状态，到这里TCP连接就断开了，四次挥手完成

为什么客户端要等待2MSL？

1、主要原因是为了保证客户端发送那个的第一个ACK报文能到到服务器，因为这个ACK报文可能丢失，并且2MSL是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃，这样新的连接中不会出现旧连接的请求报文。

​ 保证第一个ACK报文，能够在网络中被丢弃。

2、最后一个ACK数据报丢失，需要等待 服务端 重传

网络连接状态详解

共有12中可能的状态，前面11种是按照TCP连接建立的三次握手和TCP连接断开的四次挥手过程来描述的：

  1. LISTEN：首先服务端需要打开一个socket进行监听，状态为 LISTEN，侦听来自远方TCP端口的连接请求 ；
  2. SYN_SENT：客户端通过应用程序调用connect进行active open，于是客户端tcp发送一个SYN以请求建立一个连接，之后状态置为 SYN_SENT，在发送连接请求后等待匹配的连接请求；
  3. SYN_RECV：服务端应发出ACK确认客户端的 SYN，同时自己向客户端发送一个SYN，之后状态置为，在收到和发送一个连接请求后等待对连接请求的确认；
  4. ESTABLISHED：代表一个打开的连接，双方可以进行或已经在数据交互了， 代表一个打开的连接，数据可以传送给用户；
  5. FIN_WAIT1：主动关闭(active close)端应用程序调用close，于是其TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态， 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
  6. CLOSE_WAIT：被动关闭(passive close)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序)，并进入CLOSE_WAIT， 等待从本地用户发来的连接中断请求；
  7. FIN_WAIT2：主动关闭端接到ACK后，就进入了 FIN-WAIT-2，从远程TCP等待连接中断请求；
  8. LAST_ACK：被动关闭端一段时间后，接收到文件结束符的应用程 序将调用CLOSE关闭连接，这导致它的TCP也发送一个 FIN,等待对方的ACK.就进入了LAST-ACK，等待原来发向远程TCP的连接中断请求的确认；
  9. TIME_WAIT:在主动关闭端接收到FIN后，TCP 就发送ACK包，并进入TIME-WAIT状态，等待足够的时间以确保远程TCP接收到连接中断请求的确认；
  10. CLOSING: 比较少见，等待远程TCP对连接中断的确认；
  11. CLOSED: 被动关闭端在接受到ACK包后，就进入了closed的状态，连接结束，没有任何连接状态；
  12. UNKNOWN：未知的Socket状态；

Http协议

Http 1.0 Http 1.1 Http 2.0

聊聊大家都爱问的HTTP1.0和2.0的区别 - 掘金 (juejin.cn)

HTTP1.0和HTTP1.1的一些区别

  1. 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  2. 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
  3. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
  4. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

HTTP1.0和1.1现存的一些问题

  1. HTTP1.x在传输数据时，每次都需要重新建立连接，无疑增加了大量的延迟时间，特别是在移动端更为突出。
  2. HTTP1.x在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，这在一定程度上无法保证数据的安全性。
  3. HTTP1.x在使用时，header里携带的内容过大，在一定程度上增加了传输的成本，并且每次请求header基本不怎么变化，尤其在移动端增加用户流量。
  4. 虽然HTTP1.x支持了keep-alive，来弥补多次创建连接产生的延迟，但是keep-alive使用多了同样会给服务端带来大量的性能压力，并且对于单个文件被不断请求的服务(例如图片存放网站)，keep-alive可能会极大的影响性能，因为它在文件被请求之后还保持了不必要的连接很长时间。

HTTPS与HTTP的一些区别

  1. HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
  2. HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有 传输的内容都经过加密的。
  3. HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
  4. HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

HTTP2.0的新特性

  1. 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
  2. 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
  3. header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
  4. 服务端推送（server push），HTTP2.0具有server push功能。

HTTP协议中的请求方式

GET：用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD：获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
PATCH： 客户端向服务器传送的数据取代指定的文档的内容(部分取代)
TRACE： 回显客户端请求服务器的原始请求报文，用于”回环”诊断
DELETE： 删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS： 查询相应URI支持的HTTP方法。

  • GET to read
  • POST to create
  • PUT to update
  • DELETE to remove

HTTPS协议

超文本传输安全协议（英语：HyperText Transfer Protocol Secure)

流程

HTTP SSL TCP TLS 说的啥 - 腾讯云开发者社区-腾讯云 (tencent.com)

HTTPS 选择了两种混用，如图，由于 HTTPS 涉及到大量的接口、数据等非常频繁的操作行为，所以如果一概采用非对称加密的话，会严重影响 HTTPS 的性能，因此传输的数据的加密方式应该采用对称加密，而对称加密的秘钥在通讯两端同步的时候容易被截获，因此，HTTPS 采用非对称加密的方式来对该对称秘钥进行传输。通过这两种加密方式的结合，HTTPS 有效地避免性能损耗的同时，也让数据传输安全性得到了保障

img

SSL 和 TLS

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS 记录协议和 TLS 握手协议。

SSL 和 TLS 是一种能够在服务器，machines 和通过网络运行的应用程序（列如，客户端连接到 web 服务器）之间提供身份认证和数据加密的加密协议。SSL是TLS的前世。多年来，新版本的发布用来解决漏洞，提供更强大支持，更安全的密码套件和算法。

SSL最初是由 Netscape 开发的，早在1995年以SSL 2.0的方式发布（1.0从未对公众发布）。在一些漏洞被发现之后，版本2.0在1996年很快被3.0所取代。注意：版本2.0和3.0有时会写成 SSLv2 和 SSLv3。

TLS以SSL 3.0为基础于1999年作为SSL的新版本推出。

1
TLS/SSL 在传输网络层连接进行加密。 TLS/SSL 是安全传输层协议 Transporter Layer Security 是介于 TCP 和 Http 之间的一层安全协议, 不影响原有的 TCP 协议和 Http 协议。

TLS 握手

img

​

HTTPS加密（握手）过程 - 简书 (jianshu.com)

img

TLS协议是基于TCP协议之上的，图中第一个蓝色往返是TCP的握手过程，之后两次橙色的往返，我们可以叫做TLS的握手。握手过程如下：

  • client1：TLS版本号+所支持加密套件列表+希望使用的TLS选项
  • Server1:选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS选项+（要求客户端证书）；
  • Client2:(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥（自己生成的一个随机值）；
  • Server2:使用私钥解密出对称秘钥（随机值）后，发送加密的Finish消息，表明完成握手

img

CA验证过程

HTTPS原理和TLS认证流程全解析 - 知乎 (zhihu.com)

这时收到两份证书后，客户端会通过以下流程一步一步验证是否可信：

  1. 通过域名核对，找出所要访问的服务端的证书A，即小米证书；
  2. 通过证书A的Issuer找到其颁发者证书B，即中间证书RapidSSL；
  3. 通过证书B的Issuer找到根证书C，发现其已内置在本地，然后用证书C的公钥解密证书B的签名取出摘要1，再用同样的哈希算法计算出证书B的摘要2，两者比对，如果一致，就证明证书B是可信的；
  4. 用同样的方法，取证书B的公钥解密证书A的签名，比对摘要相等后也证明了证书A是可信的，这时验证过程就完成了，这时就可以拿证书A的公钥去做加密Random3进行下一步握手流程了。

以上一层层地认证过程就叫做认证链。这就像生活中的熟人生意，比如，我和马云认识，互相信任，而马云和马化腾认识，也互相信任，但我不认识马化腾，如果我和他做生意担心被坑，这时通过马云的介绍，我和马化腾也认识了，后面做生意也就放心了。

img

TCP / UDP

TCP（Transmission Control Protocol），又叫传输控制协议，UDP（User Datagram Protocol），又叫用户数据报协议，

tcp/udp协议和应用场景 - one*love - 博客园 (cnblogs.com)

tcp和udp的应用场景

什么时候应该使用TCP：

当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。

　　在日常生活中，常见使用TCP协议的应用如下：

　　浏览器，用的HTTP

　　FlashFXP，用的FTP

　　Outlook，用的POP、SMTP

　　Putty，用的Telnet、SSH

　　QQ文件传输

什么时候应该使用UDP：

　　当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。

　　比如，日常生活中，常见使用UDP协议的应用如下：

　　QQ语音

　　QQ视频

　　TFTP

TCP

TCP 协议如何保证可靠传输

停止等待：每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
超时重传：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
拥塞控制： 当网络拥塞时，可能会造成网络的拥堵，甚至网络瘫痪，TCP会减少数据的发送。
数据包校验：TCP 将保持它首部和数据的检验和，这是一个端到端的检验和。目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
丢弃重复数据：TCP 的接收端会丢弃重复的数据。

TCP拥塞控制？

拥塞控制是防止过多的数据注入网络，使得网络中的路由器或者链路过载。流量控制是点对点的通信量控制，而拥塞控制是全局的网络流量整体性的控制。发送双方都有一个拥塞窗口（cwnd）。

慢开始：最开始发送方的拥塞窗口为1，由小到大递增。每经过一个传输轮次，拥塞窗口cwnd加倍（乘2）。当cwnd超过慢开始门限，则使用拥塞避免算法，避免cwnd增长过长。
拥塞避免（算法）：当cwnd超过慢开始门限，每经过一个往返时间RTT，cwnd就增长1。在慢开始和拥塞避免过程中，一旦发现网络拥塞，就把慢开始门限设置为当前值的一半，并且重新设置cwnd为1，重新慢启动。
快重传：接收方每收到一个失序的报文段后就立即发出重复确认，发送方只要收到3个重复确认就立即重传。
快恢复：当发送方连续收到三个重复确认，就将慢开始门限减半，将当前的窗口设置为慢开始门限，并采用拥塞避免算法。（采用快恢复算法时，慢开始只在建立连接和网络超时时才使用）

Restful架构

Fielding将他对互联网软件的架构原则，定名为REST，即Representational State Transfer的缩写。我对这个词组的翻译是”表现层状态转化”。

如果一个架构符合REST原则，就称它为RESTful架构。

要理解RESTful架构，最好的方法就是去理解Representational State Transfer这个词组到底是什么意思，它的每一个词代表了什么涵义。如果你把这个名称搞懂了，也就不难体会REST是一种什么样的设计。

三、资源（Resources）

REST的名称”表现层状态转化”中，省略了主语。”表现层”其实指的是”资源”（Resources）的”表现层”。

所谓”资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。

所谓”上网”，就是与互联网上一系列的”资源”互动，调用它的URI。

四、表现层（Representation）

“资源”是一种信息实体，它可以有多种外在表现形式。我们把”资源”具体呈现出来的形式，叫做它的”表现层”（Representation）。

比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。

URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的”.html”后缀名是不必要的，因为这个后缀名表示格式，属于”表现层”范畴，而URI应该只代表”资源”的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对”表现层”的描述。

五、状态转化（State Transfer）

访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。

互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生”状态转化”（State Transfer）。而这种转化是建立在表现层之上的，所以就是”表现层状态转化”。

客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

六、综述

综合上面的解释，我们总结一下什么是RESTful架构：

　　（1）每一个URI代表一种资源；

　　（2）客户端和服务器之间，传递这种资源的某种表现层；

　　（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现”表现层状态转化”。

七、误区

RESTful架构有一些典型的设计误区。

最常见的一种设计错误，就是URI包含动词。因为”资源”表示一种实体，所以应该是名词，URI不应该有动词，动词应该放在HTTP协议中。

举例来说，某个URI是/posts/show/1，其中show是动词，这个URI就设计错了，正确的写法应该是/posts/1，然后用GET方法表示show。

如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是：

　　POST /accounts/1/transfer/500/to/2

正确的写法是把动词transfer改成名词transaction，资源不能是动词，但是可以是一种服务：

　　POST /transaction HTTP/1.1
　　Host: 127.0.0.1
　　
　　from=1&to=2&amount=500.00

另一个设计误区，就是在URI中加入版本号：

　　http://www.example.com/app/1.0/foo

　　http://www.example.com/app/1.1/foo

　　http://www.example.com/app/2.0/foo

因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept字段中进行区分（参见Versioning REST Services）：

　　Accept: vnd.example-com.foo+json; version=1.0

　　Accept: vnd.example-com.foo+json; version=1.1

　　Accept: vnd.example-com.foo+json; version=2.0

Socket通信

介于应用层和运输层(传输层)之间

TCP/UDP之上

socket通信和tcp通信的区别是什么-常见问题-PHP中文网

在这里插入图片描述

RPC协议

RPC简介及框架选择 - 简书 (jianshu.com)

理论

本地过程调用

RPC就是要像调用本地的函数一样去调远程函数。在研究RPC前，我们先看看本地调用是怎么调的。假设我们要调用函数Multiply来计算lvalue * rvalue的结果:

1
2
3
4
5
6
7
8
1 int Multiply(int l, int r) {
2    int y = l * r;
3    return y;
4 }
5 
6 int lvalue = 10;
7 int rvalue = 20;
8 int l_times_r = Multiply(lvalue, rvalue);

那么在第8行时，我们实际上执行了以下操作：

  1. 将 lvalue 和 rvalue 的值压栈
  2. 进入Multiply函数，取出栈中的值10 和 20，将其赋予 l 和 r
  3. 执行第2行代码，计算 l * r ，并将结果存在 y
  4. 将 y 的值压栈，然后从Multiply返回
  5. 第8行，从栈中取出返回值 200 ，并赋值给 l_times_r

以上5步就是执行本地调用的过程。（20190116注：以上步骤只是为了说明原理。事实上编译器经常会做优化，对于参数和返回值少的情况会直接将其存放在寄存器，而不需要压栈弹栈的过程，甚至都不需要调用call，而直接做inline操作。仅就原理来说，这5步是没有问题的。）

远程调用

远程过程调用带来的新问题

在远程调用时，我们需要执行的函数体是在远程的机器上的，也就是说，Multiply是在另一个进程中执行的。这就带来了几个新问题：

  1. **[Call ID映射](https://www.zhihu.com/search?q=Call ID映射&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra={“sourceType”%3A”answer”%2C”sourceId”%3A221638079})**。我们怎么告诉远程机器我们要调用Multiply，而不是Add或者FooBar呢？在本地调用中，函数体是直接通过函数指针来指定的，我们调用Multiply，编译器就自动帮我们调用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以，在RPC中，所有的函数都必须有自己的一个ID。这个ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，必须附上这个ID。然后我们还需要在客户端和服务端分别维护一个 {函数 <–> Call ID} 的对应表。两者的表不一定需要完全相同，但相同的函数对应的Call ID必须相同。当客户端需要进行远程调用时，它就查一下这个表，找出相应的Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
  2. 序列化和反序列化。客户端怎么把参数值传给远程的函数呢？在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（比如服务端用C++，客户端用Java或者Python）。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。
  3. 网络传输。远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也可以，而gRPC干脆就用了HTTP2。Java的Netty也属于这层的东西。

有了这三个机制，就能实现RPC了，具体过程如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Client端 
//    int l_times_r = Call(ServerAddr, Multiply, lvalue, rvalue)
1. 将这个调用映射为Call ID。这里假设用最简单的字符串当Call ID的方法
2. 将Call ID，lvalue和rvalue序列化。可以直接将它们的值以二进制形式打包
3. 把2中得到的数据包发送给ServerAddr，这需要使用网络传输层
4. 等待服务器返回结果
5. 如果服务器调用成功，那么就将结果反序列化，并赋给l_times_r

// Server端
1. 在本地维护一个Call ID到函数指针的映射call_id_map，可以用std::map<std::string, std::function<>>
2. 等待请求
3. 得到一个请求后，将其数据包反序列化，得到Call ID
4. 通过在call_id_map中查找，得到相应的函数指针
5. 将lvalue和rvalue反序列化后，在本地调用Multiply函数，得到结果
6. 将结果序列化后通过网络返回给Client

所以要实现一个RPC框架，其实只需要按以上流程实现就基本完成了。

其中：

  • Call ID映射可以直接使用函数字符串，也可以使用整数ID。映射表一般就是一个哈希表。
  • 序列化反序列化可以自己写，也可以使用Protobuf或者FlatBuffers之类的。
  • 网络传输库可以自己写socket，或者用asio，ZeroMQ，Netty之类。

当然，这里面还有一些细节可以填充，比如如何处理网络错误，如何防止攻击，如何做流量控制，等等。但有了以上的架构，这些都可以持续加进去。

最后，有兴趣的可以看我们自己写的一个小而精的RPC库 Remmy（hjk41/Remmy)），对于理解RPC如何工作很有好处。

组件: Client, Client Stub, Server, Server Stub

1
2
3
4
5
6
7
客户端（Client），服务的调用方。

服务端（Server），真正的服务提供者。

客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。

服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法

img

img

实现

(6条消息) 深入浅出 RPC - 深入篇_mindwind-_-的博客-CSDN博客

img

流程说明：

RPC 服务方通过 RpcServer 去导出（export）远程接口方法，

而客户方通过 RpcClient 去引入（import）远程接口方法。客户方像调用本地方法一样去调用远程接口方法，

RPC 框架提供接口的代理实现，实际的调用将委托给代理RpcProxy 。

代理封装调用信息并将调用转交给RpcInvoker 去实际执行。

在客户端的RpcInvoker 通过连接器RpcConnector 去维持与服务端的通道RpcChannel，并使用RpcProtocol 执行协议编码（encode）并将编码后的请求消息通过通道发送给服务方。

RPC 服务端接收器 RpcAcceptor 接收客户端的调用请求，

同样使用RpcProtocol 执行协议解码（decode）。

解码后的调用信息传递给RpcProcessor 去控制处理调用过程，

最后再委托调用给RpcInvoker 去实际执行并返回调用结果。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1. RpcServer
   负责导出（export）远程接口
2. RpcClient
   负责导入（import）远程接口的代理实现
3. RpcProxy
   远程接口的代理实现
4. RpcInvoker
   客户方实现：负责编码调用信息和发送调用请求到服务方并等待调用结果返回
   服务方实现：负责调用服务端接口的具体实现并返回调用结果
5. RpcProtocol
   负责协议编/解码
6. RpcConnector
   负责维持客户方和服务方的连接通道和发送数据到服务方
7. RpcAcceptor
   负责接收客户方请求并返回请求结果
8. RpcProcessor
   负责在服务方控制调用过程，包括管理调用线程池、超时时间等
9. RpcChannel
   数据传输通道

Web工作方式 - 访问流程

03.1. Web 工作方式 | 第三章. Web 基础 |《Go Web 编程》| Go 技术论坛 (learnku.com)

我们平时浏览网页的时候，会打开浏览器，输入网址后按下回车键，然后就会显示出你想要浏览的内容。在这个看似简单的用户行为背后，到底隐藏了些什么呢？

对于普通的上网过程，系统其实是这样做的：浏览器本身是一个客户端，当你输入 URL 的时候，首先浏览器会去请求 DNS 服务器，通过 DNS 获取相应的域名对应的 IP，然后通过 IP 地址找到 IP 对应的服务器后，要求建立 TCP 连接，等浏览器发送完 HTTP Request（请求）包后，服务器接收到请求包之后才开始处理请求包，服务器调用自身服务，返回 HTTP Response（响应）包；客户端收到来自服务器的响应后开始渲染这个 Response 包里的主体（body），等收到全部的内容随后断开与该服务器之间的 TCP 连接。

img

图 3.1 用户访问一个 Web 站点的过程

一个 Web 服务器也被称为 HTTP 服务器，它通过 HTTP 协议与客户端通信。这个客户端通常指的是 Web 浏览器 (其实手机端客户端内部也是浏览器实现的)。

Web 服务器的工作原理可以简单地归纳为：

客户机通过 TCP/IP 协议建立到服务器的 TCP 连接
客户端向服务器发送 HTTP 协议请求包，请求服务器里的资源文档
服务器向客户机发送 HTTP 协议应答包，如果请求的资源包含有动态语言的内容，那么服务器会调用动态语言的解释引擎负责处理 “动态内容”，并将处理得到的数据返回给客户端
客户机与服务器断开。由客户端解释 HTML 文档，在客户端屏幕上渲染图形结果
一个简单的 HTTP 事务就是这样实现的，看起来很复杂，原理其实是挺简单的。需要注意的是客户机与服务器之间的通信是非持久连接的，也就是当服务器发送了应答后就与客户机断开连接，等待下一次请求。

URL 和 DNS 解析

我们浏览网页都是通过 URL 访问的，那么 URL 到底是怎么样的呢？

URL (Uniform Resource Locator) 是 “统一资源定位符” 的英文缩写，用于描述一个网络上的资源，基本格式如下

1
2
3
4
5
6
7
scheme://host[:port#]/path/.../[?query-string][#anchor]
scheme         指定底层使用的协议(例如：http, https, ftp)
host           HTTP 服务器的 IP 地址或者域名
port#          HTTP 服务器的默认端口是 80，这种情况下端口号可以省略。如果使用了别的端口，必须指明，例如 http://www.cnblogs.com:8080/
path           访问资源的路径
query-string   发送给 http 服务器的数据
anchor         锚

DNS (Domain Name System) 是 “域名系统” 的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它用于 TCP/IP 网络，它从事将主机名或域名转换为实际 IP 地址的工作。DNS 就是这样的一位 “翻译官”，它的基本工作原理可用下图来表示。

img

图 3.2 DNS 工作原理

更详细的 DNS 解析的过程如下，这个过程有助于我们理解 DNS 的工作模式

在浏览器中输入 www.qq.com 域名，操作系统会先检查自己本地的 hosts 文件是否有这个网址映射关系，如果有，就先调用这个 IP 地址映射，完成域名解析。

如果 hosts 里没有这个域名的映射，则查找本地 DNS 解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。

如果 hosts 与本地 DNS 解析器缓存都没有相应的网址映射关系，首先会找 TCP/IP 参数中设置的首选 DNS 服务器，在此我们叫它本地 DNS 服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。

如果要查询的域名，不由本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，完成域名解析，此解析不具有权威性。

如果本地 DNS 服务器本地区域文件与缓存解析都失效，则根据本地 DNS 服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地 DNS 就把请求发至 “根 DNS 服务器”，“根 DNS 服务器” 收到请求后会判断这个域名 (.com) 是谁来授权管理，并会返回一个负责该顶级域名服务器的一个 IP。本地 DNS 服务器收到 IP 信息后，将会联系负责 .com 域的这台服务器。这台负责 .com 域的服务器收到请求后，如果自己无法解析，它就会找一个管理 .com 域的下一级 DNS 服务器地址 (qq.com) 给本地 DNS 服务器。当本地 DNS 服务器收到这个地址后，就会找 qq.com 域服务器，重复上面的动作，进行查询，直至找到 www.qq.com 主机。

如果用的是转发模式，此 DNS 服务器就会把请求转发至上一级 DNS 服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根 DNS 或把转请求转至上级，以此循环。不管是本地 DNS 服务器用是是转发，还是根提示，最后都是把结果返回给本地 DNS 服务器，由此 DNS 服务器再返回给客户机。

img

图 3.3 DNS 解析的整个流程

所谓 递归查询过程 就是 “查询的递交者” 更替，而 迭代查询过程 则是 “查询的递交者” 不变。

举个例子来说，你想知道某个一起上法律课的女孩的电话，并且你偷偷拍了她的照片，回到寝室告诉一个很仗义的哥们儿，这个哥们儿二话没说，拍着胸脯告诉你，甭急，我替你查 (此处完成了一次递归查询，即，问询者的角色更替)。然后他拿着照片问了学院大四学长，学长告诉他，这姑娘是 xx 系的；然后这哥们儿马不停蹄又问了 xx 系的办公室主任助理同学，助理同学说是 xx 系 yy 班的，然后很仗义的哥们儿去 xx 系 yy 班的班长那里取到了该女孩儿电话。(此处完成若干次迭代查询，即，问询者角色不变，但反复更替问询对象) 最后，他把号码交到了你手里。完成整个查询过程。

通过上面的步骤，我们最后获取的是 IP 地址，也就是浏览器最后发起请求的时候是基于 IP 来和服务器做信息交互的。

HTTP 协议详解

HTTP 协议是 Web 工作的核心，所以要了解清楚 Web 的工作方式就需要详细的了解清楚 HTTP 是怎么样工作的。

HTTP 是一种让 Web 服务器与浏览器 (客户端) 通过 Internet 发送与接收数据的协议，它建立在 TCP 协议之上，一般采用 TCP 的 80 端口。它是一个请求、响应协议 – 客户端发出一个请求，服务器响应这个请求。在 HTTP 中，客户端总是通过建立一个连接与发送一个 HTTP 请求来发起一个事务。服务器不能主动去与客户端联系，也不能给客户端发出一个回调连接。客户端与服务器端都可以提前中断一个连接。例如，当浏览器下载一个文件时，你可以通过点击 “停止” 键来中断文件的下载，关闭与服务器的 HTTP 连接。

HTTP 协议是无状态的，同一个客户端的这次请求和上次请求是没有对应关系，对 HTTP 服务器来说，它并不知道这两个请求是否来自同一个客户端。为了解决这个问题， Web 程序引入了 Cookie 机制来维护连接的可持续状态。

HTTP 协议是建立在 TCP 协议之上的，因此 TCP 攻击一样会影响 HTTP 的通讯，例如比较常见的一些攻击：SYN Flood 是当前最流行的 DoS（拒绝服务攻击）与 DdoS（分布式拒绝服务攻击）的方式之一，这是一种利用 TCP 协议缺陷，发送大量伪造的 TCP 连接请求，从而使得被攻击方资源耗尽（CPU 满负荷或内存不足）的攻击方式。

HTTP 请求包（浏览器信息）
我们先来看看 Request 包的结构，Request 包分为 3 部分，第一部分叫 Request line（请求行）, 第二部分叫 Request header（请求头）, 第三部分是 body（主体）。header 和 body 之间有个空行，请求包的例子所示:

GET /domains/example/ HTTP/1.1 // 请求行: 请求方法 请求 URI HTTP 协议/协议版本
Host：www.iana.org // 服务端的主机名
User-Agent：Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 // 浏览器信息
Accept：text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 // 客户端能接收的 mine
Accept-Encoding：gzip,deflate,sdch // 是否支持流压缩
Accept-Charset：UTF-8,*;q=0.5 // 客户端字符编码集
// 空行,用于分割请求头和消息体
// 消息体,请求资源参数,例如 POST 传递的参数
HTTP 协议定义了很多与服务器交互的请求方法，最基本的有 4 种，分别是 GET, POST, PUT, DELETE。一个 URL 地址用于描述一个网络上的资源，而 HTTP 中的 GET, POST, PUT, DELETE 就对应着对这个资源的查，增，改，删 4 个操作。我们最常见的就是 GET 和 POST 了。GET 一般用于获取 / 查询资源信息，而 POST 一般用于更新资源信息。

通过 fiddler 抓包可以看到如下请求信息:

图 3.4 fiddler 抓取的 GET 信息

图 3.5 fiddler 抓取的 POST 信息

我们看看 GET 和 POST 的区别:

我们可以看到 GET 请求消息体为空，POST 请求带有消息体。
GET 提交的数据会放在 URL 之后，以 ? 分割 URL 和传输数据，参数之间以 & 相连，如 EditPosts.aspx?name=test1&id=123456。POST 方法是把提交的数据放在 HTTP 包的 body 中。
GET 提交的数据大小有限制（因为浏览器对 URL 的长度有限制），而 POST 方法提交的数据没有限制。
GET 方式提交数据，会带来安全问题，比如一个登录页面，通过 GET 方式提交数据时，用户名和密码将出现在 URL 上，如果页面可以被缓存或者其他人可以访问这台机器，就可以从历史记录获得该用户的账号和密码。
HTTP 响应包（服务器信息）
我们再来看看 HTTP 的 response 包，他的结构如下：

1
2
3
4
5
6
7
8
HTTP/1.1 200 OK                     // 状态行
Server: nginx/1.0.8                 // 服务器使用的 WEB 软件名及版本
Date: Tue, 30 Oct 2012 04:14:25 GMT     // 发送时间
Content-Type: text/html             // 服务器发送信息的类型
Transfer-Encoding: chunked          // 表示发送 HTTP 包是分段发的
Connection: keep-alive              // 保持连接状态
Content-Length: 90                  // 主体内容长度
// 空行 用来分割消息头和主体
计算机基础
#计算机网络 #计算机基础
计算机网络
http://example.com/2023/06/01/计算机基础/计算机网络/
作者
where
发布于
2023年6月1日
许可协议