[TOC]

应用层协议原理

网络应用程序体系

客户-服务器

典型的web应用，需要服务器主机一直运行，随时处理来自客户端的请求；对于大型网站来说，单个的服务器不能应对海量的请求，配备大量主机的数据中心常用来创建强大的虚拟服务器；

P2P体系结构

对服务器没有依赖或者依赖很小，两个主机之间直接进行通信，优点很明显不需要厂家提供海量的服务器，每个用户主机的资源都可以作为服务的一部分，缺点是稳定性和安全性难得到保障

进程通信

最终进行通信的单元是进程不是程序，这里也不会太多的研究同一主机上的进程间通信，来看看跨越计算机网络交换报文的不同端系统上的进程间的通信

客户和服务器进程

在web应用中很明显浏览器进程是客户进程，但对于P2P来说呢，我们认为发起通信的进程是客户，等待联系的进程是服务器

进程与计算机网络之间的接口

套接字：如上所述，多数应用程序是有通信进程对组成，相互发送报文，这些报文必须通过下层网络进行传输，定义了一个叫套接字（socket）的软件接口来让进程发送和接收报文
API：套接字是应用层和传输层之间的接口，也称为应用程序和网络之间的应用程序编程接口（API），开发者可以控制套接字在应用层的一切，但对套接字在运输层端几乎没有控制权，能选择运输层协议和少量的参数配置

进程寻址

为了向目标主机上的进程发送分组，接收进程需要有一个地址，需要定义两种信息：主机的地址（IP）、目标主机中接收进程的标识符（端口号）

可供应用程序使用的运输服务

运输层存在不同的传输协议，提供了不同的服务，我们对服务特性进行分类：可靠数据传输、吞吐量、定时和安全性

可靠数据传输

之前说过，分组传输可能因为路由缓存耗尽而丢失或者比特损坏等，出现数据丢失；一些应用像电子邮件、文件传输、金融应用等不能接受数据的丢失，为了支持这些应用，需要确保应用程序在一端发出的数据能完全正确的交付给另一端，提供这样服务的协议就具有了可靠数据传输的特性

像通话这样的应用是可以接受数据丢失的

吞吐量

由于分组在网络上是共享带宽的方式进行传输的，所以本身并不能保证自己能占用多少带宽，但对于及时通话或者视频这样的带宽敏感的应用来说，如果带宽不能稳定的大于某个阈值，那它的服务将服务提供，这个时候就需要传输协议能保证传输带宽至少大于阈值

定时

这里说的定时其实是说保证比特到达接收方的时间不超过阈值，也就是保证延时

安全性

这个很好理解，比如https

因特网提供的运输服务

因特网提供两个运输层协议，UDP和TCP

TCP

面向连接的服务：在完成握手之后，一个TCP链接就在两个进程套接字之间建立了，在这个连接里面两个进程可以同时进行报文的收发
可靠的数据传输服务
拥塞控制：当发现传输网络出现拥塞时，TCP会抑制发送进程来缓解网络压力
安全性：无论是TCP还是UDP都没有提供任何的加密机制，数据是以明文在网络上传递的，可以被中间链路嗅探
SSL（secure sockets layer）：安全套接字层，SSL是对TCP的加强而不是运输层上的第三种协议，而且这个地方的非对称加密是在应用层上实现的

UDP

UDP是一个轻量级的运输协议，无连接、不可靠数据传输、没有拥塞控制，应用场景比较少（电话应用），基本被TCP替代

因特网运输协议不提供的服务

可以看出TCP没有提供吞吐量和定时相关的服务，因特网有别的方式来提供这两种服务，后面会探讨

会涉及的网络应用

由于网络应用种类太多，这里只会主要介绍常见的几种：Web、文件传输、电子邮件、目录服务、流式视频和P2P

Web和HTTP

上世界90年代以前，因特网只是众多的数据网络中的一个，它的主要使用者是研究人员和学者不为大众所知，正是万维网（world Wide Web）的出现引起了公众的注意，因特网开始一枝独秀

HTTP概况

web的应用层协议是HTTP，先看一些基础概念!

web页面：由对象组成，可以是一个HTML文件、图片、小程序或者视频之类的数据，可以通过一个URL地址寻址。于是可以相互引用
HTTP：定义了客户想服务器请求的方式，以及服务器向客户传送页面的方式，使用TCP作为传输协议，两端通过套接字接口进行通信，一旦数据发送之后，就不再由端系统控制，进入TCP的控制；而且服务器并不会记录客户的任何信息，我们称HTTP为无状态协议，且服务器总是打开的具有一个固定的IP

非持续连接和持续链接

非连续连接就是说，客户端和服务器的一次请求和响应完成后连接就断开，下次请求重新建立连接，这样的问题是频繁的创建销毁连接带来资源开销，而且如果一个客户端同时有多个请求会建立多个连接，连接规模会比较大

持续连接即使说不要立马断开，下次请求还可以通过这个连接进行通信，会有一个超时时间来断开连接，如果有多个请求是可以并发的进行，而不是串行的

HTTP报文格式

有请求报文和响应报文，具体的内容就那些，列到这里意义不大，该记不住的还是记不住

由于http本身是无状态的，所以通过cookie来维护一些用户的活动，登录、访问记录、身份识别权限控制等；cookie的使用其实是对用户隐私的一种侵犯，所以要求网站需要得到用户的授权之后才能使用

web缓存

在局域网内加入一个web缓存器，这样重复的请求不需要进入公网链路，由于局域网带宽一般是很高的响应快，且极大的减轻公网链路的传输压力

条件get方法

上面说了添加web缓存服务器，带来一个问题，如果真正的服务器上的信息发生了改变，那缓存如何处理，GET提供了一种条件请求，if-modified-since:时间，缓存服务器向真实的服务器发送条件请求，只有当这个时间点之后服务器上的结果发生了变化才返回真正的结果，如果没有变化则只返回一些响应头数据，不包含真正的dat，这样报文体积就很小对网络带宽没有多少占用

因特网中的电子邮件

电子邮件应该是因特网中最早的一个流行应用，直至今日也仍然是因特网上最重要和实用的应用程序之一

电子邮件系统组成

用户代理：允许用户阅读、回复、转发、保存和撰写报文
邮件服务器：
简单邮件传输协议：

DNS：因特网的目录服务

DNS提供的服务

DNS工作机理概述

DNS记录和报文

P2P文件分发

上面的结构都是服务器和客户端，现在有一个场景，服务器要向大量的客户端推送一个系统的版本更新，体积为2G，如果所有的客户端都去服务器上下载数据，那对服务器的带宽要求太高了

用到P2P文件分发，每个对等方能够向任何其他对等方重新发送它已经收到的该文件的任何部分，减小服务器压力，目前最流行的P2P文件分发协议是BitTorrent

P2P体系结构的扩展性

书上用了一大堆公式来进行推导，最终的结论就如图中展示的样子，服务器的模式下耗时是线性增长的，P2P模式下用户规模的扩展不会带来太多耗时的增长

BitTorrent

来简单的介绍一下这个协议的原理，由于其真实的实现非常复杂，了解核心思维即可

参与某个文件分发的所有对等方集合称为一个洪流，文件被拆分为文件块在对等方间传输，典型的大小是256KB，洪流中总是有新的对等方加入和老的对等方离开
每个洪流具有一个追踪器，每个对等方都在追踪器中注册自己并周期性的通知追踪器自己还在洪流中，以此来同步对等方信息
现在加入小张加入了一个洪流，目前洪流中有50个对等方，追踪器会将这50个对等方的IP发给小张，小张尝试和他们进行TCP交易，建立成功的称为邻近对等方
小张会周期性的查询（所有的通讯都通过TCP进行）邻近对等方所持有的块，接下来需要解决两个核心问题，小张该从她的邻居那请求那些块，第二小张该向哪些邻居发送块
小张会去请求她没有的块里面最稀缺的数据，稀缺就是说在邻居上副本数据少的数据，目的也好理解，为了大致均衡每个块在洪流中的副本数量
小张会持续的测量从邻居那里接收比特的速率，并记录Top4速度列表，每10秒检测更新这个列表，这top4称为疏通，一直更新也没有用，引入新的竞争者，每30s会随机的向一个邻居发送数据，同理也会有一个随机邻居小刘向小张发送数据，如果小刘发送数据的速度比现在的top4更快自然top4就会重新洗牌；也就是说同时只会有5个对等方可以和小张进行数据传输

视频流和内容分发网

事先录制好的视频流（非及时）基本占用了住宅ISP一半的流量，这里我们来看看是怎么进行传输的

因特网视频

视频是由连续播放的图片组成的，图片又是由像素矩阵构成，图像的特点是能被压缩，现今的技术允许视频被压缩到任意比特率

HTTP和DASH

通过HTTP get请求客户端和服务器之间建立一个TCP连接，进行数据传输，达到设定的阈值之后就开始播放，且继续传输后面的数据；HTTP的方式存在一个严重的缺陷是只能传输同一比特率的视频，本质就是有一个视频文件放到了服务器上，然后进行传输嘛，所以大家拿到的都是同一个视频文件

DASH（Dynamic Adaptive Streaming over HTTP）：动态适应流，基于HTTP将视频压缩为不同码率的版本放到服务器，客户动态的请求来自不同版本且长度为几秒的视频段数据块，这样当用户的带宽出现波动的时候，也能在不同比特率的块上进行切换；自动切换的原理就是看带宽速率能不能满足播放的需求

内容分发网 CDN

CDN的基础概念不在这里描述了，两种服务器安置原则

深入：即是在遍及全球的接入ISP中部署服务器（1700个），通过靠近端用户来提升速率
邀请做客：在少量的关键位置（10个）部署大集群，不是将集群接入ISP，而是放置在因特网交换点（IXP），成本低，但是效果不如深入原则

CDN也不能把数据都复制到每个节点上，所以采用热度淘汰的策略来进行分布式存储

CDN操作

比如公司智线云的产品FN上有很多视频内容，智线云是个小公司不能自己部署一套CDN，于是使用了阿里云提供的CDN，用户请求视频数据的流程为：

用户访问FN web网页
用户点击视频内容，用户主机发送了一个请求，用户本地DNS服务器将请求中继到智线云的DNS服务器，该服务器发现请求资源是视频的时候向用户DNS返回一个阿里云CDN的主机名
用户DNS向阿里云CDN主机发送请求，阿里云CDN的DNS系统会指定一个具体的CDN服务器并返回IP，用户将从这台服务器上获取数据
用户DNS向用户主机转发了CDN服务器IP，用户将和这个IP建立TCP连接进行通信

实际上操作的时候，数据应该事先被放到阿里云的CDN上，网页上直接就是写的阿里云CDN提供的链接，用户通过这个链接访问CDN数据

集群选择策略

在上面的案例中，阿里云CDN是如何选择让哪个集群来响应用户请求的呢

最直接的就是从地理上的最近来进行响应，不错的策略，但是实际情况下用户的DNS有可能远离用户的，这里的地理最近是从用户DNS来进行计算的，另外网络还存在带宽以及时延等现实的问题
比较好的策略是实时测量，CDN的每个集群都周期性的向位于全世界的所有用户DNS发送探测分组来测量时延和丢包，缺陷是许多的DNS被配置为不会响应这些探测LOL

案例：Netflix、YouTube

Netflix

使用了亚马逊云，新电影发布前，将数据上传到亚马逊云的主机上，并转化为不同的格式以及比特率，然后将这些处理后的不同版本数据上载到CDN上
Netflix 2007年起搭建了自己的CDN，在IXP和他们自己的住宅ISP中安装服务器机架，当前有超过50个IXP上安装了机架，Netflix还会联系ISP免费的安装机架，这些机架具有几个10Gbps的以太网端口和超过100T的存储
Netflix的CDN并不通过拉高速缓存的方式进行数据分发，通过主动推送的方式，将流行的视频在非高峰时段推送到CDN服务器

YouTube

同样适用CDN来分发视频，与Netflix不同，Google使用了拉高速缓存的方式来进行同步,和Netflix一样也使用自己专用的CDN，YouTube不使用DSAH而是让用户自行选择

迅雷看看

迅雷使用P2P交付的方式来传输流视频，看看在使用CDN-P2P混合流式系统，用户从CDN请求内容开头的部分，并从对等方请求内容，当P2P流量可以满足视频播放时，停止向CDN请求，极大降低了基础设施服务器成本

套接字编程

之前也介绍过，不同的开发者使用相同的协议进行编程，可以让不同的应用进行交互，下面会实现简单的TCP和UDP协议程序

UDP套接字编程

书上给出了demo，本地测试可以，但是和服务器之间的通信失败了