由于 HTTP 协议是无状态的，需要浏览器协助保存会话信息。当用户在网站上登录后，服务器将认证信息通过 Cookie 等手段保存在浏览器中。随后发起 HTTP 请求时，浏览器将自动携带 Cookie 数据，以此保持认证状态。

用户在网站上的一切操作，比如发邮件、发消息，甚至是银行转账，都是通过 HTTP 请求进行的。只要用户的登录认证信息尚未过期，浏览器就会自动将其带上，从而让 HTTP 请求通过认证。

利用这一点，黑客可以诱导用户在一个已认证过的浏览器上执行非本意操作，并从中非法牟利。这就是臭名昭著的 跨站请求伪造（ cross-site request forgery ），简称 CSRF 。

CSRF 利用网站对用户浏览器的信任，诱导用户访问一个自己登录过的网站，并发出非本意的请求。因为像 Cookie 这样的简单身份验证机制，只能保证请求是由认证过的浏览器发出的，而不能保证请求一定出于用户本意。

攻击原理

HTTP 是一种无状态的应用协议，请求和请求之间在协议层面是互相独立的。因此，Web 网站通常在用户登录后，将认证信息保存在浏览器 Cookie 中，以便后续的请求能够顺利通过认证。以某银行网银 somebank.com 为例：

上一小节，我们通过一个实验，深入地研究了 TCP 三次握手建立连接的过程。

我们退出 telnet 命令后，TCP 将关闭连接。于此同时，我们通过 tcpdump 也观察到 TCP 关闭连接的通信过程。本节，我们继续深入研究 TCP 关闭连接的通信细节。

上节实验的通信过程，已经被抓包并保存起来，我们直接用 tcpdump 命令将其打开（ tcp.pcap ）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

root@client [ ~ ]  ➜ tcpdump -nr tcp.pcap
reading from file tcp.pcap, link-type LINUX_SLL (Linux cooked v1)
17:31:57.624391 ARP, Request who-has 10.0.0.2 tell 10.0.0.3, length 28
17:31:57.624439 ARP, Reply 10.0.0.2 is-at 0e:bd:60:1c:69:9d, length 28
17:31:57.624450 IP 10.0.0.3.55692 > 10.0.0.2.22: Flags [S], seq 386101196, win 29200, options [mss 1460,sackOK,TS val 811948031 ecr 0,nop,wscale 7], length 0
17:31:57.624495 IP 10.0.0.2.22 > 10.0.0.3.55692: Flags [S.], seq 1155103769, ack 386101197, win 28960, options [mss 1460,sackOK,TS val 3541712191 ecr 811948031,nop,wscale 7], length 0
17:31:57.624522 IP 10.0.0.3.55692 > 10.0.0.2.22: Flags [.], ack 1, win 229, options [nop,nop,TS val 811948031 ecr 3541712191], length 0
17:31:57.635739 IP 10.0.0.2.22 > 10.0.0.3.55692: Flags [P.], seq 1:42, ack 1, win 227, options [nop,nop,TS val 3541712202 ecr 811948031], length 41
17:31:57.635778 IP 10.0.0.3.55692 > 10.0.0.2.22: Flags [.], ack 42, win 229, options [nop,nop,TS val 811948042 ecr 3541712202], length 0
17:31:59.808411 IP 10.0.0.3.55692 > 10.0.0.2.22: Flags [F.], seq 1, ack 42, win 229, options [nop,nop,TS val 811950215 ecr 3541712202], length 0
17:31:59.809175 IP 10.0.0.2.22 > 10.0.0.3.55692: Flags [.], ack 2, win 227, options [nop,nop,TS val 3541714376 ecr 811950215], length 0
17:31:59.809464 IP 10.0.0.2.22 > 10.0.0.3.55692: Flags [F.], seq 42, ack 2, win 227, options [nop,nop,TS val 3541714376 ecr 811950215], length 0
17:31:59.809483 IP 10.0.0.3.55692 > 10.0.0.2.22: Flags [.], ack 43, win 229, options [nop,nop,TS val 811950216 ecr 3541714376], length 0

经过前面学习，我们知道查询一个域名，需要与 DNS 服务器进行通信。那么，DNS 通信过程大概是怎样的呢？

DNS 是一个典型的 Client-Server 应用，客户端发起域名查询请求，服务端对请求进行应答：

DNS 一般采用 UDP 作为传输层协议（ TCP 亦可），端口号是 53 。请求报文和应答报文均作为数据，搭载在 UDP 数据报中进行传输：

一个 IP 包需要经过一系列路由的转发，才能到达目的地。下图是一个典型的例子，一个从主机 ant 出发，去往主机 apple 的 IP 包，需要经过中间路由 R1 、R2 以及 R3 ：

traceroute命令

分析网络问题、排查网络故障时，我们经常需要知道：去往某个 IP 的数据包需要经过哪些路由？那么，有办法将通往某个 IP 的路由路径找出来吗？

其实是有的，traceroute 命令就可以做到。traceroute 命令是一个很常用的网络工具，你可能已经听过，甚至已经用过了。它可以用来探测、跟踪去往某个目的地 IP 包需要经过的路由路径。

我们已经学习了 HTTP 协议的通信细节，那么如何编程发起 HTTP 请求呢？

现成类库

现代高级程序开发语言，基本都内置了现成的 HTTP 请求库，直接调用即可。以 Python 为例，标准库中提供了 urllib.request 模块用于发起 HTTP 请求：

1
2
3
4
5
6
7
8

>>> import urllib.request
>>> with urllib.request.urlopen('http://cors.fasionchan.com/about.txt') as response:
...   print(response.read().decode('utf8'))
...
作者：fasionchan
网站：https://fasionchan.com
微信公众号：小菜学编程

这段代码请求 http://cors.fasionchan.com/about.txt 这个地址，并将服务器响应的文本资源打印到屏幕上。现成类库将大量通信细节隐藏起来，短短几行代码即可实现目的，因此更加简单易用。

尽管如此，如果只会调用现成类库，而不懂底层通信细节，容易沦为 API 调用侠，不利于开发能力发展。因此，本节打算从建立 TCP 连接开始，介绍如何一步步请求 HTTP 服务。

TCP 协议与包括 UDP 在内的其他传输层协议的主要差别在于：数据传输质量 。UDP 协议将数据发送出去之后就不管了，但 TCP 还会对已发送的数据进行跟踪，以防丢失。这样就有效地实现了 TCP 协议的两个关键特性：

• 可靠性（ reliability ），保证数据可靠送到目的地（如有丢失，必须能够检测出来，并重传）；
• 流量控制（ flow control ），控制数据发送速度，以免冲垮接收方；

为实现这两个设计目标，TCP 协议引入了所谓的 滑动窗口（ sliding window ）机制。理解滑动窗口机制，是掌握 TCP 协议的关键，也是学习其他 TCP 知识的前提。本节带领大家将滑动窗口机制一举拿下！

经过前面学习，我们初步掌握了域名系统的基本原理。

我们知道，域名可以和指定的 IP 进行关联，进而充当 IP 的别名。我们通过域名来访问网络服务时，域名系统会帮我们将域名解析成对应的 IP 地址。

那么，域名是否只能关联 IP 地址呢？其实并不是。除了 IP 地址，域名还可以关联其他类型的信息。

实际上，域名和与之关联的信息，就构成了一条 DNS记录 （ DNS record ）。DNS记录可以理解成一个键值对：

• 键：域名；
• 值：与域名关联的值；

为实现可靠传输，TCP 实现了接收确认机制：当数据发生丢包时，重传数据。当网络链路负载很重，甚至发生拥塞时，丢包就会很频繁。这时如果 TCP 还拼命地重传数据，将进一步压垮网络！

为了避免网络拥塞时压垮网络，TCP 还实现了 拥塞控制 机制，主要包含这几个算法：

• 慢启动
• 拥塞避免
• 快速重传
• 快速恢复

网络拥塞

每条网络线路都有一定的带宽上限，如果承载于其上的网络流量超过带宽，丢包就不可避免。这就是所谓的 网络拥塞（ network congestion ），一种持续过载的网络状态，网络传输质量下降。

如下图，主机 ant 和 apple 之间有段链路发生网络拥塞，两台主机间的通信必然受到影响：

如果主机不知道网络拥塞的发生，还拼命地发送数据，最终肯定会进一步压垮网络链路。

小菜在一家互联网公司工作，负责后台开发。他们公司有一个 APP ，运营需要分析用户操作体验。为此，研发团队准备在 APP 中埋点，以便上报数据。而小菜需要提供一个后端服务，用来接收 APP 上报的数据。

小菜开发好数据接收服务后，申请了一个域名，让 APP 团队通过域名提交数据。这样一来，小菜以后可以灵活地调整后端服务，随意扩容、缩容，甚至是迁移，完全不用 APP 团队配合。

本节我们通过一个玩具 TCP 服务应用，来观察 TCP 协议的通信过程，进而体会它的关键知识点：

• 服务端
• 客户端
• 端口
• TCP连接
• 套接字

实验应用

实验应用是一个最简化的玩具应用，由服务端和客户端组成：