按照上一篇的想法，计算机网络要解决的问题，是远程方法调用的问题。应用层可以用一个方法来描述。response_obj apply(address,port,rmethod,rparams,protocol）。response_obj 为返回对象，address为远程服务机器地址，port为远程服务进程监听端口，rmethod为远程方法，rparmas为远程方法入参，protocol为入参。
对于address这个参数来说，如果address的值是一个域名，例如www.jianshu.com。域名并不是外网地址，所以互联网有一个统一的注册服务中心DNS，类似zookeeper在rpc中提供的服务。DNS提供的服务主要做的是域名到外网IP的映射。类似这样的结构{"www.jianshu.com" : ["121.9.244.88"]}。如果是入参是ip，则不需要做域名到ip的映射。如果入参是域名，通过DNS服务解析为ip就可以。
DNS域名解析服务走的是UDP协议。为什么要设计成走UDP协议，而不走TCP协议呢？从设计上来说，UDP是异步的方式，TCP是同步的方式。在互联网上，设备数量是亿级别，走同步方式，对DNS服务的压力太大。设计成异步，类似MQ的方式处理，可以削峰填谷。
port这个参数，对于指定协议来说，一般都是按照默认指定端口，http对于80，https对应443;rmethod方法是服务的方法，这个是远程服务方法定义；rparams是方法应用参数，也就是业务参数；protocol是协议，如http,smtp等。protocol的意义在于定义了address,port,rmethod,rparam这四个参数，编码，解码规则。对于运输层来说，一切都是stream,编码做的就是四个参数的值做按照一定规则做流编码。服务端收到流，再按照协议解码流。
HTTP协议
rmethod就是url，入参rparams是方法请求参数。rparams请求参数可以是二进制文件，也可以是文本信息。因为对于tcp来说，都是流，所以，http的头需要设置入参的元信息。有了元信息，服务端才能根据报文头的元信息解析流。服务端有了方法，入参数据，就可以处理业务逻辑，返回结果。http协议某种程度上和本地方法调用是一样的，都是调用方法请求，然后响应结果。也就是所谓的请求-响应模型。
http是无状态协议，为了可以让不同用户协同工作，服务端需要维护用户登陆信息，所以引进了session这个概念。假如用户信息由客户端自己存储，每次请求都携带上用户信息，服务端也就不需要维护session了。
为了提高访问的吞吐量，http协议同样做了缓存设计，http协议中既包括数据，也包括操作指令，例如重定向，缓存。
http协议就是规则，或者说是规范。规范是需要实现的，实现规范后就是一个http通讯api。http应用的场景，第三方服务的restful服务，例如环信的im服务；还有就是基于浏览器的应用，例如微信。
SMTP协议
邮件的转移的过程是，代理客户端A->代理服务器B->目标服务器C->目标客户端D，也就是A推送消息到B，B推送消息到C，D在通过拉取的方式从C读取消息。B服务器有持久化邮件信息的功能，B推送C，失败的话，也有重试的功能。C同样有持久化消息的功能。某种程度上，C服务器就是一个邮件管理系统，D客户端就是管理界面。
从架构的角度看，我们可以学到，从一个状态转移事务，如果是设计为异步的方式，是需要做补偿设计的，例如重试机制。
DNS协议
DNS域名系统是一个分布式架构的服务。分布式的好处是可以避免单点故障，服务的吞吐量大。DNS服务做了层次结构的划分。根据域名查询ip，是按照最近的服务递归查询。
P2P协议
p2p解决的问题是什么？解决的是高并发读压力下，带宽限制了吞吐量的问题。假如视频服务网站上有一个200M的视频，10w的用户同时在看，那么对于服务器来说，压力太大了，并且会拖慢用户的下载文件的速度。除了用CDN缓存手段，我们可以怎么设计，应对这个问题？
假设我们把200M的视频，拆分为100个2M的文件，100个文件都有一个唯一的值标志，例如md5值。客户端A下载了f01这个文件，能不能也开启一个服务，通知有下载需求的客户端B，我这里有f01这个文件，你可以来我这里下载，不用挤破头去服务器tracker那里下载。这样子的话，服务器的压力就下降下来了。除了储存原始文件，服务器的职责变成了记录在这个小群体中，文件在拓扑网络中的分布情况，一张文件分布地图。
当客户端C需要下载视频，那么会首先拿到这张地图，根据这种地图去拓扑网络中拿需要的文件，得到最终的文件。
