WEB应用 #

HTTP 超文本传输协议 HyperText Transfer Protocol #

HTTP是一种采用C/S结构的HTTP。**它是基于TCP的**一种应用层协议。常见的服务器软件为Apache Web Server.

无状态协议 #

服务器不维护本次请求之前的其他该同一用户发出的请求消息。例如，两分钟前请求过一次，两分钟后再请求也没有区别。

为什么使用无状态？因为如果有状态就需要维护这个状态。那么状态多了，有限状态机就负责了。且如果一方不正常就会导致状态不同步，引发严重问题。

两次握手建立连接 #

由于采用C/S模型，所以是客户机主动向服务器发送请求，然后服务器应答这种请求。

这种方式，无论是建立连接还是传输数据都采用了。

HTTP客户端首先根据URL中的主机名拿到IP地址，对该IP地址的80端口发起TCP连接请求（客户机主动创建Socket，请求TCP连接）。

然后服务器接受此连接，并发送ACK给客户端。（此前，服务器的80端口一直在等待连接）

两次握手资源请求应答 #

根据IP地址建立TCP连接之后，HTTP客户端向服务器发送URL中的请求路径部分，向服务器请求该资源（SOCKET实现）。然后服务器返回应答（SOCKET实现）。这就是典型的C/S模型。

持久性连接和非持久性连接 #

HTTP 1.1 #

在HTTP 1.0，CS之间总是进行一轮资源请求应答就结束TCP连接了。

但是这存在问题，因为一个页面包含多个对象，但是非持久性连接意味着对于每个对象请求都要进行TCP连接的建立和拆除。则完全加载了网页的所有对象可能需要数百次TCP连接。这显然效率过低。

在HTTP 1.1后，采用持久性连接，即一个TCP连接可以进行多次资源请求，再断开TCP连接。

RTT #

即Round Trip Time，从客户端发送数据报到服务器并收到返回的ACK的时间。

非持久性连接的效率 #

请求和接收一个对象需要 2RTT+t(trans).

无流水机制的持久性连接的效率 #

客户端收到上一个请求的应答后，才发出新的请求。

显然每个对象需要1RTT+t(trans)的时间。

有流水机制的持久性连接的效率 #

客户端同时对所有需要请求的对象进行请求。

在带宽无穷的情况下，把一个页面上的所有对象请求并收到花费的总时间是1RTT+t(trans).

Cookie #

HTTP是无状态的协议。为了**实现其状态**，由此引入Cookie.

网站对用户进行Session跟踪，在客户机本地存储相关数据。这些数据一般是加密的，通过在HTTP Request、HTTP Response头中添加一行“Cookie 头部行”完成Cookie交换。

Cookie在客户端由浏览器维护，在服务端存储于数据库，由服务器软件维护。

用户第一次请求服务器，请求头中不带有cookie字段。服务器得知这是一个新用户，为其建立数据库新入口，在HTTP res中增加cookie设置字段，让这个用户的浏览器设置此cookie。下次用户再请求，请求头中就存在cookie字段了，服务器查询数据库发现这是个存在的老用户，与是为其提供个性化HTTP res。

代理服务器Proxy技术（Web缓存技术） #

Proxy工作机制 #

在无需访问服务器的情况下，就能满足客户端的HTTP请求。具体方式是客户机直接把**所有的**HTTP请求都发给其Proxy，如果Proxy上有，则直接满足客户机的请求；如果Proxy上没有，Proxy就充当客户机去给目标服务器发出HTTP请求，得到相应后返回给客户机，并留一份副本给自己。

因此，Proxy同时充当客户机和服务器的角色。

Proxy缓存更新：选择性GET #

Proxy每次给目标服务器发送HTTP req时，在请求头内添加如下入口：

If-modified-since: <date>

如果服务器要响应的页面的最后更改时间早于这个date，则返回：

HTTP Status 304/ Not Modified

从而告知Proxy，当前缓存仍为最新，无需给你更新。

否则，返回HTTP 200 OK，并且带有新的响应数据。

Proxy的好处 #

如果公司机构在自己局域网下架设Proxy，则可以提升局域网内部链路利用率，降低互联网接入链路负担，同时显著提升主机访问互联网的速度（假设Proxy**命中率**为0.2-0.7）。

例如内部链路是10Mbps，Internet接入链路是1.5Mbps，则如果占满Internet接入链路，则内部链路的利用率仅到15%；而且Internet接入链路由于负载过大，路由器饱和，访问延迟趋近于无穷，则用户访问互联网的时间都被这条链路耽误了；

如果在内部架设一个Proxy，则有很多请求只需要在内网内就被消化，内网链路上跑的数据量不再被Internet接入链路带宽所局限，即内网链路数据率在本例中可以>1.5Mbps。同时，也因此，Internet接入链路的负担下降，路由器不至于饱和，就算Proxy不命中，也不会让Internet访问的路由器等待时间趋近无穷了。

相比拓宽Internet接入链路，仅仅架设一个Proxy，效率提升更加明显，且更加便宜。

Email应用 #

SMTP简单邮件传输协议 Simple Mail Transfer Protocol #

SMTP和HTTP1.1一样，也是基于TCP的持久性连接协议。常用段口25.它们的报文也都是采用ASCII码，具有人类可读性。

SMTP是异步协议。协议双方不要求同时进行通信。这也决定了电子邮件可以不像聊QQ那样即时通信，不要求双方在线状态，非常方便。

SMTP服务端 #

服务端主要维护两个部分：邮件存储和发送队列。其中，邮件存储存储了所有拥有账户的用户的邮件，负责供用户查看；发送队列负责接收来自用户的邮件，并发送给其他SMTP服务器。

SMTP客户端 #

负责查看邮件、撰写邮件（即直接与自己账号所在的Mail Server利用SMTP交互）。

例如查看邮件，Mail Server从存储中把邮件给客户端；例如发送邮件，客户端把邮件给Mail Server的发送队列。

MIME 多媒体邮件扩展 #

最初的SMTP只支持ASCII格式的消息体。之后，引入MIME，从而可以将消息体采用其他编码，例如中文、图片视频等。具体编码方法等声明在SMTP消息**头部**。

POP邮局协议Post Office Protocol #

用户发送邮件给自己的SMTP服务器、SMTP服务器之间的通信都使用SMTP协议，但是最后一步，即用户从自己的SMTP服务器获取自己收到的邮件，可以采用POP协议。

POP协议首先完成Authentacation，然后客户就可以从自己对应的SMTP服务器上下载收到的邮件了。

POP3协议 #

包含登陆验证命令和邮件管理（事务）命令。例如列出信息、删除信息、下载信息。

POP3是无状态的协议。 #

如题。

IMAP互联网邮件访问协议 Internet Mail Access Protocol #

IMAP是一个有状态的协议。用户无论从哪里登陆，得到的自定义设置都是保持一致的。

IMAP允许搜索、创建文件夹等。

HTTP协议也可以用来收发邮件 #

在基于WEB应用的邮件客户端，例如mail.qq.com上，采用HTTP协议来实现类似IMAP、POP的功能。

DNS系统 Domain Name System #

DNS是互联网上一个非常核心的系统。它解决了互联网上主机的**识别问题。DNS维护一个庞大的分布式的分层的数据库**系统。

对于DNS中的单个DNS服务器来说，是C/S模型。

DNS结构 #

使用分布式数据库 #

为了避免单点故障问题、高并发问题。

为了全世界访问，把这个DNS放在哪个国家都不合适。（距离问题），因此可以在全世界很多地方放置DNS。

使用分层次数据库（共三层） #

这三层分别是 Root DNS、TLD DNS、权威DNS。

这里面不包含本地DNS。因为本地DNS不应该纳入全球DNS系统，本地DNS只是起到Proxy的作用。

Root DNS掌握各TLD DNS（例如.com DNS服务器）的IP；各TLD DNS服务器掌握此TLD下各权威DNS服务器的信息（例如amazon.com）。如果要查询amazon.com的IP地址，则先询问Root，再找到.com TLD DNS，再找到amazon.com 权威DNS，最后amazon.com DNS返回IP地址。

本地DNS #

当本地DNS无法解析域名，直接访问Root DNS.

缓存和代理 #

本地DNS的作用类似于WEB应用中的Proxy。即代理客户机去询问Root DNS，并作缓存（设置TTL）。

本地DNS常常会访问TLD DNS的IP，所以一般Root DNS访问此处会比较少。这样也有利于分散Root DNS负载。

本地DNS从哪来，我又没在本地假设？ #

本地DNS由所在ISP提供。在Windows的网络配置中，可以手动填写或者由DHCP自动获取。

Root DNS #

如果不清楚Domain-IP映射，访问权威DNS，然后向请求方（一般是本地DNS）返回此Domain-IP映射。

顶级域名服务器 TLD DNS, Top-Level Domain DNS #

这些服务器包含了顶级域名，例如.com（由特定组织维护）、.cn（由国家维护）。

权威DNS服务器, Authoritative DNS #

即网络内容提供商自己维护的DNS，用于给出自己提供的网络内容的Domain-IP映射。

比如我搭建网站，那么我再搭建一个权威DNS，对外宣称我的网站的域名是什么。

当然，这里也可以不自己搭建DNS，可以让第三方帮着你去维护这个Domain-IP映射关系，例如“阿里云 云解析DNS 产品”、“Cloudflare”。

DNS服务 #

最基本的服务：翻译Domain到IP #

客户机查询本地DNS，如果本地DNS无法解析，则可以代替客户机去询问Root DNS，并将返回的映射关系设置TTL缓存起来。

具体的查询方式分为迭代查询和递归查询。

迭代查询 #

本地DNS询问Root DNS、TLD DNS时，对方的态度是：我不知道你要的信息，但是我知道xxx可能知道这个信息，你去找xxx吧。与是返回给本地DNS一个IP地址，下一步本地DNS会去询问这个新的DNS服务器，然后重复。

递归查询 #

本地DNS询问Root DNS、TLD DNS时，对方的态度是：我不知道你要的信息，但是我可以帮你去问问。层层类推，与是，经过一段时间，本地DNS可以直接从Root DNS处拿到最终查询结果了。

区别 #

迭代查询中，DNS服务器的态度很差，不愿意帮忙；本地DNS充当了全局变量，存储状态转移信息，负责状态转移。

递归查询中，DNS服务器的态度极好，是老好人的形象；各个DNS系统中的服务器充当每一层递归调用函数，存储函数进入返回信息。

主机和邮件服务器别名 #

如果采用CNAME方式进行资源记录，则代表把某域名设置一个别名，例如从服务器提供商处拿到一个很长的域名，为了能自定义域名，可以设置别名。

如果采用MX方式，类似地，设置的是邮件服务器。

负载均衡 #

在高并发的状态下，如果这个网站是由一组服务器（服务器农场）搭建起来的，那么DNS服务器可以让这些服务器轮流接收流量。它实现一个队列，每次从队首取服务器接收负载，并把它压入队尾。

RR 域名资源记录 DNS Resource Records #

一条域名资源记录即对应一条映射关系。由Type-Name-Value三元组构成。其中Type是资源记录类型，Name是待映射的域名，Value是映射对象（可以是域名也可以是IP）。

Type	Name	Value	解释
A	域名	IP	将域名映射到IP
NS	域（理解为一级域名）	权威DNS的域名	指定域（一级域名）的DNS服务器是谁
CNAME	别名	域名	指定已有域名的别名
MX	域名	邮件服务器	映射邮件服务器

如何注册一个域名 #

搭建或寻找第三方权威DNS服务 #

自己搭建或者使用第三方的权威DNS。

在TLD管理方处解析权威DNS，并指定新域名的NS为此权威DNS #

将这个权威DNS的IP地址添加A记录到TLD管理方，并将自己新注册的这个域名在TLD管理方做NS记录，指向权威DNS的域名（之所以要先A，后NS，是因为NS只能支持将域名作为值。）。

在权威DNS上解析即可 #

例如：添加A记录到自己的主页，添加MX记录到自己的邮件服务器。

P2P应用 #

P2P应用是相对于C/S模型而言的。在P2P中，没有中心服务器负责内容的分发，反之，内容的分发是网络中各个邻居互相之间自发进行的。P2P分发网络是一张动态的网络，在任何时刻都有可能有新成员加入P2P分发网络，也可能退出P2P分发网络（例如这个人下载完毕，关闭了下载软件）。

BitTorrent 文件分发协议 #

BitTorrent是基于TCP协议的。

P2P中，文件被分成若干256KB大小的Chunk进行传输。用户通过收集这些Chunk，拼合成最终的文件。每个Chunk可以来自不同的用户，并不是所有用户都持有此文件中的任意Chunk（例如有的用户还没有下载完成，只持有部分Chunk，又或者这个用户完全没有下载这个文件的打算，所以不持有此文件的任何Chunk。）

在P2P分发网络中，每个主机只会与自己的邻居通信。这一点一定要注意。当一个新结点加入网络，它只会和自己的若干邻居建立连接。

Tracker #

P2P也不是完全的没有服务器进行管理。P2P存在一种中心服务器，称为Tracker，用于追踪记录P2P网络中，用户的相关信息。这个信息可以是P2P分发网络中有哪些结点。

新用户加入 #

新的用户加入P2P分发网络，需要向Tracker注册，获得本P2P分发网络的结点表单，并与其若干邻居**建立TCP连接**。

下载和上传是平等的 #

每个结点在下载自己没有的Chunk的同时，必须保证其同时在上传自己持有的Chunk。

这样，能保证大家是平等的。

结点获取Chunk：仅查询邻居；稀有优先。 #

结点主动查询邻居持有哪些Chunk，得知自己需要的Chunk可以从谁那里下载到。然后，向这个邻居发送Chunk获取请求。

Chunk的请求发送是稀缺优先。例如某Chunk由200个邻居持有，另一个Chunk由3个邻居所持有，则为了防止这些邻居突然下线，应当优先发出稀有Chunk的请求。

结点发送Chunk：一报还一报，感恩的心 #

前面说到，结点在下载的同时保持上传。所以结点会根据自己的下载情况决定去报答谁。

结点会选择近10秒内给自己发送速率最快的4个结点，给他们发送Chunk。每过10秒，结点都会重新评估要给哪4个结点发送Chunk。（这能更有实时性：因为说不定这30秒内就有其他新结点加入了，然后这个新结点的速率很快）

同时，每过30秒，结点会随机选择非上述Top-4的结点发送Chunk，这样可以为网络带来变化性。因为万一这个新结点逐渐成为了Top-4呢。

因此，P2P是一种互相激励资源共享的协议。只要上传速率足够高（贡献足够大），那么就会找到更多人来回报你，你的下载速率就更快。

P2P效率 #

还是以文件分发为例。

C/S模型：O(N)的分发总时间 #

假设是C/S模型，假设服务器要把文件分发N份，则需要上传N次。当N很大，则完成分发的总时间是O(N)的。

P2P模型：O(1)的分发总时间 #

P2P的先进之处在与，服务器只需要上传一份文件到P2P分发网络，这个P2P分发网络就可以自发地互相传输了（当然服务器也可以同时作为P2P网络的一个普通结点参与传输，其速率还是C/S模型中的服务器发送速率）。

则给N个结点的分发总时间，分子仍然是N倍的文件大小，但是分母是P2P网络中所有结点的传输速率和服务器发送速率的和。

可见，如果N很大，但是这同时，总的发送速率也升高了，所以所有N个机器都分发到此文件所用总时间仍然变化不大，分发的总时间是O(1)（当N很大，趋近于常数）的。

P2P索引 #

正如刚才介绍的BitTorrent，它要获取，在哪些机器上有自己所需要的Chunk，才能向他们发送获取请求。

这个查询，依靠的就是P2P索引。

集中式索引 by Napster #

结点加入时，通知中央服务器自己持有什么文件。

某个结点想要下载文件时，向中央服务器查询，然后中央服务器返回一个主机信息。

得到了此主机信息，结点就知道了要找哪个主机发送下载请求了。

缺点：（包含了集中式系统的典型问题）由于是集中式，故无法避免单点故障问题和性能瓶颈问题（中央服务器需要处理任何请求，性能完全取决于此服务器，且如果宕机就gg）。

分布式索引，泛洪式查询 by Guntella #

以某P2P分发网络的某一结点为例，它与其他邻居有TCP连接，它的这些邻居又和更多邻居有TCP连接，则以这些TCP连接为边，可以构成一个图。

某结点想要下载文件，就发出一个查询请求（Query），内容是询问是否有这个文件，并把这个请求发出，凡是收到的结点就把它泛洪。

如果这个询问传到了持有此文件的主机上，则该主机逆向发送一个查询命中信息（Query Hit），经过的结点都会逐个逆向转发，直到到达发送请求的主机处。

与是就查到了。

缺点：网络资源占用过大。

层次式索引，层次式覆盖网络 by Skype #

综合了分布式和集中式两种索引的优点。

在P2P分发网络中，引入若干超级结点，每个超级结点与若干普通结点间维持半永久TCP连接，每个超级结点之间彼此维持半永久TCP连接。每个普通结点只能和对管辖它的那个超级结点发送查询请求，而不能发送P2P的查询请求。

在这里，超级结点就类似于集中式中的中心服务器。因此，这些超级结点的职责是维护自己管辖区域的索引。但是这些中心服务器相连，又自己组成了一个高层次P2P网络，这些超级结点彼此进行泛洪算法。因此这种方式，对于子区域，是集中式；对于各个超级结点，是分布式。

集中式和层次式查询都用到了C/S模型，因此整个过程可以看作P2P和C/S的结合 #

由于需要通过一定方式获取P2P索引，所以看起来在集中式和层次式的查询方式中，主机并没有相互进行对等连接。因为这是获取P2P的过程，这种过程本身就是C/S模型（因为会用到中心索引服务器）！

但是到了真正进行文件分发的时候，还是采用P2P的方式的。此时，查询方式的条条框框都没了。