《网络是这样连接的》读书笔记3

文章目录

《网络是这样连接的》读书笔记3
- 9. 服务器端的局域网有什么玄机
- - 9.1 Web服务器的部署地点
  - - 在公司里部署Web服务器
    - 将Web服务器部署在数据中心
  - 9.2 防火墙的结构和原理
  - - 主流的包过滤方式
    - 包过滤的规则
    - 从公司内网访问公开区域的规则
    - 防火墙无法抵御的攻击
  - 9.3 通过将请求平均分配给多态服务器来平衡负载
  - - 性能不足时需要负载均衡
    - 怎样将客户端发送的请求分配到每台服务器上？
  - 9.4 利用缓存服务器分担负载
  - - 缓存服务器
    - 缓存服务器通过更新时间管理内容
    - 最原始的代理——正向代理
    - 正向代理的改良版——反向代理
    - 透明代理
  - 9.5 内容分发服务
  - - 利用内容分发服务分担负载
    - 如何找到最近的缓存服务器
    - 通过重定向服务器分配访问目标
    - 缓存的更新方法会影响性能
- 10. 请求到达Web服务器，响应返回浏览器
- - 10.1 服务器概览
  - - 客户端与服务器的区别
    - 服务器程序的结构
    - 服务器端的套接字和端口号
  - 10.2 服务器的接收操作
  - - 网卡将接收到的信号转换成数字信息
    - IP模块的接收操作
    - TCP模块如何处理连接包
    - TCP模块如何处理数据包
    - TCP模块的断开操作
  - 10.3 Web服务器程序解释请求消息并作出响应
  - - 将请求的URI转换为实际的文件名
    - 运行CGI程序
    - Web服务器的访问控制
    - 返回响应消息
  - 10.4 浏览器接收响应消息并显示内容
  - - 通过响应的数据类型判断其中的内容
    - 浏览器显示网页内容！访问完成！

9. 服务器端的局域网有什么玄机

9.1 Web服务器的部署地点

在公司里部署Web服务器

最简单的是服务器直接部署在公司网络上，并且可以从互联网直接访问。

这种方式有问题：

IP地址公有地址不足。
安全问题、服务器裸奔。

防火墙方式：防火墙的作用类似于海关，它只允许发往指定服务器的指定应用程序的网络包通过，从而屏蔽其他不允许通过的包。（当然这种方式也有问题，现在已经出现了很多可以绕过防火墙的攻击方法，因此防火墙一般需要和反病毒、非法入侵检测、访问隔离等机制并用）

将Web服务器部署在数据中心

数据中心是与运营商核心部分NOC直接连接的，或者是与运营商之间的枢纽IX直接连接的。数据中心通过高速线路直接连接到互联网的核心部分，因此将服务器部署在这里可以获得很高的访问速度，当服务器访问量很大时这是非常有效的。

数据中心设施完善：数据中心不但提供安放服务器的场地，还提供各种附加服务，如服务器工作状态监控、防火墙的配置和运营、非法入侵监控等，从这一点来看，其安全性也更高。

9.2 防火墙的结构和原理

主流的包过滤方式

（当然这是成书那个时期）

只允许发往特定服务器中的特定应用程序的包通过，然后屏蔽其他的包。

包过滤的规则

在设置包过滤规则时，首先要观察包是如何流动的。

限制接收方IP地址和发送方IP地址。
通过端口号限定应用程序。

如果要允许访问除Web之外的其他应用程序，则只要将该应用程序的端口号设置到防火墙中并允许通过就可以了。
通过控制位判断连接方向

这里就需要用到TCP头部中的控制位。

通过接收方IP地址、发送方IP地址、接收方端口号、发送方端口号、TCP控制位这些条件，我们可以判断出通信的起点和终点、应用程序种类，以及访问的方向。

不过，实际上也存在无法将希望允许和阻止的访问完全区分开的情况，例如DNS使用UDP，没有连接操作，因此无法像TCP一样根据控制位来判断访问方向。

从公司内网访问公开区域的规则

我们不仅要设置互联网和公开区域之间的包过滤规则，还需要设置公司内网和互联网之间，或者公司内网与公开区域之间的包过滤规则。

包过滤方式的防火墙不仅可以允许或者阻止网络包的通过，还具备地址转换功能。

防火墙并不特殊。

包过滤并不是防火墙专用的一种特殊机制，而是应该看作在路由器的包转发功能基础上附加的一种功能。只不过当判断规则比较复杂时，通过路由器的命令难以维护这些规则，而且对阻止的包进行记录对于路由器来说负担也比较大，因此才出现了专用的硬件和软件。如果规则不复杂，也不需要记录日志，那么用内置包过滤功能的普通路由器来充当防火墙也是可以的。

防火墙无法抵御的攻击

防火墙只关心包的起点和终点，而不关心包的内容。

有一些攻击，只有检查包的内容才能识别这种风险，因此防火墙对这种情况无能为力。

要应对这种情况有两种方法。

这个问题的根源在于Web服务器程序的Bug，因此修复Bug防止宕机就是其中一种方法。
另一种方法就是在防火墙之外部署用来检查包的内容并阻止有害包的设备或软件。

有问题：因为包的内容是否有风险，是由Web服务器有没有Bug决定的，因此当服务器程序中有潜在的Bug并且尚未被发现时，我们也无法判断包中的风险，也无法阻止这样的包。

9.3 通过将请求平均分配给多态服务器来平衡负载

性能不足时需要负载均衡

服务器的访问量上升时，增加服务器线路的带宽是有效的，但并不是网络变快了就可以解决所有的问题。而是服务器的处理性能不够。

当很多用户同时访问时，无论服务器的性能再好，仅靠一台服务器还是难以胜任的。在这种情况下，使用多台服务器来分担负载的方法更有效。这种架构统称为分布式架构。

分布式是伴随着计算机和互联网发展中的一个总要特性，并非是什么新奇的东西。

可以部署多态服务器。

怎样将客户端发送的请求分配到每台服务器上？

轮询如果在DNS服务器中填写多个名称相同的记录，则每次查询时DNS服务器都会按顺序返回不同的IP地址

缺点：
1. 假如多台Web服务器中有一台出现了故障，这时我们希望在返回IP地址时能够跳过故障的Web服务器，然而普通的DNS服务器并不能确认Web服务器是否正常工作，因此即便Web服务器宕机了，它依然可能会返回这台服务器的IP地址，（当然，可以让浏览器请求解析）
2. 通过CGI等方式动态生成网页的情况下，有些操作是要跨多个页面的，如果这期间访问的服务器发生了变化，这个操作就可能无法继续。
使用负载均衡器分配访问

要用负载均衡器的IP地址代替Web服务器的实际地址注册到DNS服务器上。

客户端会认为负载均衡器就是一台Web服务器，并向其发送请求，然后由负载均衡器来判断将请求转发给哪台Web服务器。

这里的关键点不言而喻，那就是如何判断将请求转发给哪台Web服务器。
1. 是否跨多个页面
2. 如果操作没有跨多个页面，则可以根据Web服务器的负载状况来进行判断。负载均衡器可以定期采集Web服务器的CPU、内存使用率，并根据这些数据判断服务器的负载状况，也可以向Web服务器发送测试包，根据响应所需的时间来判断负载状况。
3. 当操作跨多个页面时，则不考虑Web服务器的负载，而是必须将请求发送到同一台Web服务器上
  
  HTTP本身无状态，通过IP地址判断是不是同一个请求？
  
  不行？如果用到代理服务器，就无法通过IP地址判断。
4. 可以在发送表单数据时在里面加上用来表示关联的信息，或者是对HTTP规格进行扩展，在HTTP头部字段中加上用来判断相关性的信息，Cookie。

9.4 利用缓存服务器分担负载

缓存服务器

缓存服务器就是一种按功能来分担负载的方法。缓存服务器是一台通过代理机制对数据进行缓存的服务器。

代理介于Web服务器和客户端之间，具有对Web服务器访问进行中转的功能。当进行中转时，它可以将Web服务器返回的数据保存在磁盘中，并可以代替Web服务器将磁盘中的数据返回给客户端。这种保存的数据称为缓存。

缓存服务器通过更新时间管理内容

从客户端来看，缓存服务器就相当于Web服务器。接下来，缓存服务器会检查请求消息的内容，看看请求的数据是否已经保存在缓存中。

我们假设不存在缓存数据。这时，缓存服务器会在HTTP头部字段中添加一个Via字段，表示这个消息经过缓存服务器转发，然后将消息转发给Web服务器，通过请求消息的URI中的目录名来进行判断发往那个服务器。

缓存服务器会以客户端的身份向目标Web服务器发送请求消息。（本质上是带有缓存的代理，代理商。。）

这种在客户端和Web服务器之间充当中间人的方式就是代理的基本原理。

缓存中没有数据的情况：

缓存中有数据的情况：

最原始的代理——正向代理

代理机制最早就是放在客户端一侧的，这才是代理的原型，称为正向代理（forward proxy）。

两个目的：

缓存
防火墙

它会先接收来自客户端的请求消息，然后再转发到互联网中，这样就可以实现只允许通过必要的网络包了。这时，如果能够利用代理的缓存，那么效果就会更好，因为对于以前访问过的数据，可以直接从位于公司内网的代理服务器获得，这比通过低速线路访问互联网要快很多。

由于代理在转发过程中可以查看请求的内容，所以可以根据内容判断是否允许访问。也就是说，通过代理可以禁止员工访问危险的网站，或者是与工作内容无关的网站。

在使用正向代理时，一般需要在浏览器的设置窗口中的“代理服务器”一栏中填写正向代理的IP地址。

对转发目标Web服务器的判断上。使用正向代理时，URI部分为http://…．这样的完整网址，因此可以根据这个网址来转发，不需要像服务器端的缓存服务器一样实现设置好转发目标Web服务器，而且可以发给任意Web服务器。

正向代理的改良版——反向代理

设置浏览器非常麻烦，容易发生故障。

反向代理（reverse proxy）：前面介绍的服务器端的缓存服务器采用的正是这种方式。

透明代理

缓存服务器判断转发目标的方法还有一种，那就是查看请求消息的包头部。只要知道了这个地址，就知道用户要访问哪台服务器了[插图]。这种方法称为透明代理（transparent proxy）。

（HTTP 1.1 版本增加了一个用于表示访问目标 Web 服务器的 Host 字段，因此也可以通过 Host 字段来判断转发目标。）

因此不需要像正向代理一样设置浏览器参数，也不需要在缓存服务器上设置转发目标，可以将请求转发给任意Web服务器。

我们必须将透明代理放在请求消息从浏览器传输到Web服务器的路径中，当消息经过时进行拦截。

因此一般是将网络设计成只有一条路可以走的结构，然后在这一条路径上放置透明代理。连接互联网的接入网就是这样一个关口，因此可以在接入网的入口处放置反向代理[插图]。使用透明代理时，用户不会察觉到代理的存在，也不会注意到HTTP消息是如何被转发的，因此大家更倾向于将透明代理说成是缓存。

9.5 内容分发服务

利用内容分发服务分担负载

缓存服务器放在服务器端：可以减轻Web服务器的负载。

缓存服务器放在客户端：减少互联网中的流量。

Web服务器运营者和网络运营商签约，将可以自己控制的缓存服务器放在客户端的运营商处。缓存服务器部署在距离用户很近的地方，同时Web服务器运营者还可以控制这些服务器。

筛选出一些主要的运营商，这样可以减少缓存服务器的数量。

为了方便，一些专门从事相关服务的厂商出现了，他们来部署缓存服务器，并租借给Web服务器运营者。这种服务称为内容分发服务。（内容分发服务也叫 CDS（Content Delivery Service）。（现在更常用的名称叫 CDN（Content Delivery Network 或 Content Distribution Network））

提供这种服务的厂商称为CDSP内容分发服务运营商。

他们会与主要的供应商签约，并部署很多台缓存服务器。另一方面，CDSP会与Web服务器运营者签约，使得CDSP的缓存服务器配合Web服务器工作。

缓存服务器可以缓存多个网站的数据，因此CDSP的缓存服务器就可以提供给多个Web服务器的运营者共享。每个网站运营者的平均成本就降低了，网站运营者也节省了精力。

如何找到最近的缓存服务器

第一个方法是像负载均衡一样用DNS服务器来分配访问

如果要让用户访问最近的缓存服务器，则不应采用轮询方式，而是应该判断客户端与缓存服务器的距离，并返回距离客户端最近的缓存服务器IP地址。
事先从缓存服务器部署地点的路由器收集路由信息，例如，在这4台服务器的部署地点又分别有4台路由器，则我们需要分别获取这4台路由器的路由表，并将4张路由表集中到DNS服务器上。

DNS服务器根据路由表查询从本机到DNS查询消息的发送方，也就是客户端DNS服务器的路由信息。

可以查出路由器A到客户端DNS服务器的路由。通过互联网内部的路由表中的路由信息可以知道先通过运营商X，然后通过运营商Y，最后到达运营商Z这样的信息，通过这样的信息可以大致估算出距离。

依次查询所有路由器的路由表之后，我们就可以通过比较找出哪一台路由器距离客户端DNS服务器最近。提供路由表的路由器位于缓存服务器的位置，而客户端DNS服务器也应该和客户端在同一位置，这样就等于估算出了缓存服务器与客户端之间的距离。

通过重定向服务器分配访问目标

HTTP规格中定义了很多头部字段，其中有一个叫作Location的字段。当Web服务器数据转移到其他服务器时可以使用这个字段，它的意思是“您要访问的数据在另一台服务器上，请访问那台服务器吧。”这种将客户端访问引导到另一台Web服务器的操作称为重定向。

当使用重定向告知客户端最近的缓存服务器时，首先需要将重定向服务器注册到Web服务器端的DNS服务器上。

重定向服务器和刚才一种方法中的DNS服务器一样，收集了来自各个路由器的路由信息，并根据这些信息找到最近的缓存服务器，然后将缓存服务器的地址放到Location字段中返回响应。这样，客户端就会重新去访问指定的缓存服务器了。

缺点;增加了HTTP消息的交互次数，相应的开销也比较大.

优点：重定向的方法是根据客户端发送来的HTTP消息的发送方IP地址来估算距离的，因此精度较高。

重定向服务器不仅可以返回带有Location字段的HTTP消息，也可以返回一个通过网络包往返时间估算到缓存服务器的距离的脚本，通过在客户端运行脚本来找到最优的缓存服务器。

缓存的更新方法会影响性能

一种方法是让Web服务器在原始数据发生更新时，立即通知缓存服务器，使得缓存服务器上的数据一直保持最新状态，这样就不需要每次确认原始数据是否有变化了，而且从第一次访问就可以发挥缓存的效果。内容分发服务采用的缓存服务器就具备这样的功能。

动态页面是不能保存在缓存服务器上，应用程序生成的部分，也就是每次内容都会发生变化的动态部分，与内容不会发生变化的静态部分分开，只将静态部分保存在缓存中。

Web服务器前面存在着各种各样的服务器，如防火墙、代理服务器、缓存服务器等。请求消息最终会通过这些服务器，到达Web服务器。Web服务器接收请求之后，会查询其中的内容，并根据请求生成并返回响应消息。

10. 请求到达Web服务器，响应返回浏览器

10.1 服务器概览

客户端与服务器的区别

其硬件和操作系统与客户端是有所不同的，当然客户端主机也可以充当服务器，但真正的服务器一般性能都很高。

网络相关的部分，如网卡、协议栈、Socket库等功能和客户端却并无二致。无论硬件和OS如何变化，TCP和IP的功能都是一样的，或者说这些功能规格都是统一的。

在Socket库的用法上还是有一些区别的，即应用程序调用的Socket库的程序组件不同。

服务器程序的结构

一般的做法是，每有一个客户端连接进来，就启动一个新的服务器程序，确保服务器程序和客户端是一对一的状态。

将程序分成两个模块，即等待连接模块和负责与客户端通信的模块（FTP协议也是由两类进程）

待连接模块创建套接字，然后进入等待连接的暂停状态。
当客户端连发起连接时，这个模块会恢复运行并接受连接，然后启动客户端通信模块，并移交完成连接的套接字。
客户端通信模块就会使用已连接的套接字与客户端进行通信，通信结束后，这个模块就退出了。

每次有新的客户端发起连接，都会启动一个新的客户端通信模块，因此与客户端是一对一的关系。

还有一种方法是事先启动几个客户端通信模块，当客户端发起连接时，从空闲的模块中挑选一个出来将套接字移交给它来处理。

服务器端的套接字和端口号

最好是在数据收发层面不需要区分客户端和服务器，而是能够以左右对称的方式自由发送数据。TCP也正是在这样的背景下设计出来的。

但是连接操作无法做到左右对称，连接这个操作是在有一方等待连接的情况下，另一方才能发起连接。

发起连接的一方是客户端，等待连接的一方是服务器。

这个区别体现在如何调用Socket库上。

首先，客户端的数据收发需要经过下面4个阶段。

（1）创建套接字（创建套接字阶段）
（2）用管道连接服务器端的套接字（连接阶段）
（3）收发数据（收发阶段）
（4）断开管道并删除套接字（断开阶段）

相对地，服务器是将阶段（2）改成了等待连接，具体如下。

（1）创建套接字（创建套接字阶段）
（2-1）将套接字设置为等待连接状态（等待连接阶段）
（2-2）接受连接（接受连接阶段）
（3）收发数据（收发阶段）
（4）断开管道并删除套接字（断开阶段）

一旦客户端的包到达，就会返回响应包并开始接受连接操作。接下来，协议栈会给等待连接的套接字复制一个副本，然后将连接对象等控制信息写入新的套接字中。

在复制出一个新的套接字之后，原来那个处于等待连接状态的套接字会怎么样呢？其实它还会以等待连接的状态继续存在，当再次调用accept，客户端连接包到达时，它又可以再次执行接受连接操作。

新创建的套接字副本必须和原来的等待连接的套接字具有相同的端口号。要确定某个套接字时，不仅使用服务器端套接字对应的端口号，还同时使用客户端的端口号再加上IP地址，总共使用下面4种信息来进行判断：

客户端 IP 地址
客户端端口号
服务器 IP 地址
服务器端口号

既然通过客户端IP地址、客户端端口号、服务器IP地址、服务器端口号这4种信息可以确定某个套接字，那么要指代某个套接字时用这4种信息就好了，为什么还要使用**描述符**呢？

使用描述符来指代套接字的原因如下。

等待连接的套接字中没有客户端IP地址和端口号
使用描述符这一种信息比较简单

10.2 服务器的接收操作

网卡将接收到的信号转换成数字信息

服务器将接收到的电信号还原为数字信息：

接下来需要根据包末尾的帧校验序列（FCS）来校验错误。

当FCS一致，即确认数据没有错误时，接下来需要检查MAC头部中的接收方MAC地址，看看这个包是不是发给自己的。

这里，接收信号并还原成数字信息的操作就完成了，还原后的数字信息被保存在网卡内部的缓冲区中。上面这些操作都是由网卡的MAC模块来完成的。

中断

CPU就会暂停当前的工作，并切换到网卡的任务。

网卡驱动会开始运行，从网卡缓冲区中将接收到的包读取出来，根据MAC头部的以太类型字段判断协议的种类，并调用负责处理该协议的软件。也就是交给相应的协议栈。

IP模块的接收操作

协议栈的IP模块会检查IP头部：

判断是不是发给自己的；（也可以转发）
判断网络包是否经过分片；
将包转交给TCP模块或UDP模块。

TCP模块如何处理连接包

如果收到的是发起连接的包，则TCP模块会：

确认TCP头部的控制位SYN;
检查接收方端口号；
为相应的等待连接套接字复制一个新的副本；
记录发送方IP地址和端口号等信息。

TCP模块如何处理数据包

收到数据包时，TCP模块会：

根据收到的包的发送方IP地址、发送方端口号、接收方IP地址、接收方端口号找到相对应的套接字；
将数据块拼合起来并保存在接收缓冲区中；
向客户端返回ACK。

TCP模块的断开操作

断开操作完成后，套接字会在经过一段时间后被删除。具体操作见前几章。

10.3 Web服务器程序解释请求消息并作出响应

将请求的URI转换为实际的文件名

Web服务器中，read获取的数据内容就是HTTP请求消息。服务器程序会根据收到的请求消息中的内容进行相应的处理，并生成响应消息，再通过write返回给客户端。

Web服务器公开的目录其实并不是磁盘上的实际目录，而是虚拟目录。

运行CGI程序

收到请求消息之后，Web服务器会进行下面的工作：

Web服务器会检查URI指定的文件名，看一看这个文件是不是一个程序
果判断要访问的文件为程序文件，Web服务器会委托操作系统运行这个程序，然后从请求消息中取出数据（也可以有头部字段）并交给运行的程序。
1. 如果方法为GET，则将URI后面的参数传递给程序。
2. 如果方法为POST，则将消息体中的数据传递给程序
运行的程序收到数据后会进行一系列处理，并将输出的数据返回给Web服务器。
这些输出的数据一般来说会嵌入到HTML文档中，因此Web服务器可以直接将其作为响应消息返回给客户端。
输出数据的内容是由运行的程序生成的，Web服务器并不过问，也不会去改变程序输出的内容，但是可以添加一些HTTP头部字段。

Web服务器的访问控制

Web服务器的访问控制规则主要有以下3种。

客户端IP地址
客户端域名
用户名和密码

当根据客户端域名设置规则时，需要先根据客户端IP地址查询客户端域名，这需要使用DNS服务器。根据IP地址反查域名也可以使用DNS服务器。

利用HTTP验证用户名和密码

返回响应消息

Web服务器调用Socket库的write，将响应消息交给协议栈。

告诉协议栈这个响应消息应该发给谁，但我们并不需要直接告知客户端的IP地址等信息，而是只需要给出表示通信使用的套接字的描述符就可以了。

协议栈会将数据拆分成多个网络包，然后加上头部发送出去。

这些包中包含接收方客户端的地址，它们将经过交换机和路由器的转发，通过互联网最终到达客户端。

10.4 浏览器接收响应消息并显示内容

通过响应的数据类型判断其中的内容

（客户端浏览器）要显示内容，首先需要判断响应消息中的数据属于哪种类型，原则上可以根据响应消息开头的Content-Type头部字段的值来进行判断。

Content-Type: text/html

其中“/”左边的部分称为“主类型”，表示数据的大分类；右边的“子类型”表示具体的数据类型。

此外，当数据类型为文本时，还需要判断编码方式，这时需要用charset附加表示文本编码方式的信息，内容如下。

Content-Type: text/html; charset=utf-8

因此，有时候我们需要结合其他一些信息来综合判断数据类型，例如请求文件的扩展名、数据内容的格式等。

浏览器显示网页内容！访问完成！

接下来只要根据数据类型调用用于显示内容的程序，将数据显示出来就可以了。对于HTML文档、纯文本、图片这些基本数据类型，浏览器自身具有显示这些内容的功能，因此由浏览器自身负责显示。

在读取文档数据时，一旦遇到相应的标签，浏览器就会向服务器请求其中的图片文件。这个请求过程和请求HTML文档的过程是一样。

Web服务器可能还会返回其他一些类型的数据，如文字处理、幻灯片等应用程序的数据。这些数据无法由浏览器自行显示，这时浏览器会调用相应的程序。这些程序可以是浏览器的插件，也可以是独立的程序。

到这里，浏览器的显示操作就完成了，可以等待用户的下一个动作了。当用户点击网页中的链接，或者在网址栏中输入新的网址时，访问Web服务器的操作就又开始了。

网络包的旅程