计网笔记_2
第2章 应用层
应用层内容很多，有很多协议和应用，但是这学期课程中涉及得比较少，基本只在QoS部分有所涉及，笔记里就大概罗列一下知识点。
2.1 应用层原理
应用层协议最多
可能的应用架构：C/S、peer2peer、混合架构
C/S模式：服务器ip不能动，信息数据应用都在服务器上，可扩展性可靠性比较差，随着用户访问量的增加，性能断崖式下降；
p2p模式：客户端也可以是服务器，但是管理复杂，性能不稳定，得客户端上线接入才可以作为服务器提供服务；
混合体：C/S目录查询，数据会话P2P方式。
进程通信：进程之间通信。
进程：在主机上运行的应用程序。
客户端进程：发起请求的进程；
服务器进程：等待连接的进程。
在同一个主机内，使用进程间通信机制来通信（机制由主机的操作系统定义）；
不同主机上的两个进程之间想要通信，通过交换报文message来通信。
（p2p架构的进程也有客户端进程和服务器进程之分。）
分布式进程想要通信需要解决的问题，三个：
1. 进程需要标识自己，同时标识需要带有地址信息（能够寻址）；
2. 传输层是如何向应用层提供服务的：位置（层间接口的SAP：TCP/IP socket），形式（应用程序接口API：TCP/IP socket API）；
3. 如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用：定义协议。编制程序。
第一个问题：
对进程进行编址addressing，传输的报文数据（Service Data Unit , SDU）之外：
主机IP，TCP还是UDP，以及TCP or UDP 的端口号Port（发端和收端的端口，谁传的，传给谁）。此外还需要传输层实体对这些信息进行TCP/UDP的封装（源端口号，目标端口号，数据等；将IP地址下交IP实体，用于封装IP数据报，源IP，目标IP）
第二个问题：
每次应用层到传输层都要这三个部分的信息，而且必须包含，太过繁琐易错，有没有办法简化信息量？有，就是socket。通过一个整数，四元组（TCP）或二元组（UDP），来代表源IP/源端口/目标IP/目标端口，从而简化信息并便于管理。
TCP socket是个表，包含socket、四元组和连接状态，多步填完并一直更新；
UDP socket：两进程通信之前无需建立联系，所以只有二元组，包含源IP和源端口，但是传输时，需要提供对方的IP和端口
第三个问题：
定义应用层协议：报文格式，解释，时序等；
编制程序，通过API调用网络基础设施提供通信服务传输报文，解析报文，实现应用时序等。
应用层协议：
公开协议：RFC文档定义，HTTP，SMTP
私有协议：不公开，skype
应用层需要传输层提供什么样的服务？
四个方面的性能指标：数据丢失率、延迟、吞吐量、安全性
Internet传输层提供的服务：
TCP服务：面向连接，可靠，稍慢；
UDP服务：无连接，不可靠，实时。
TCP和UDP
都不提供安全性，都不加密
TCP用SSL安全套接字（Secure Sockets Layer在应用层，因为它在应用中运行，也有说在传输层，因为它为应用提供服务）。SSL也提供SSL socket API。
2.2 Web和HTTP
一些术语terms：
Web页，由一些对象组成，对象可以是HTML文件，JEPG图像，Java程序等。
Web页需含有一个基本的HTML文件，该基本文件含有对其他若干对象的引用。
可以通过唯一的URL对任何一个互联网中的对象进行引用、访问：
URL格式：协议名/用户：口令（支持匿名访问的可以省略）/主机名/路径名/端口（设置了默认端口号的话也可以省略）
HTTP：超文本传输协议，Web的应用层协议
C/S模式
使用TCP，默认端口号为80
HTTP是无状态的，服务器不维护用户的任何信息，即通信结束之后不保留请求用户的状态。
HTTP 1.0：非持久HTTP，TCP连接请求-确认（往返时间round-trip time RTT，可忽略），http请求-返回数据信息（数据传输有耗时，不可忽略），连接关闭请求-连接关闭；
HTTP 2.0：持久HTTP，连接请求-确认，http请求-返回数据信息，之后连接不关，再有数据请求不需要重新建立连接。
1.0开始默认流水线请求方式。
HTTP请求报文的形式：ASCII码，可读
服务器提交表单方式：post方式，URL方式
用户-服务器状态：cookies
服务器向新用户分配cookie，用户访问服务器时带上cookie，服务器就可以关联用户行为，从而可以维护客户端状态。
Web缓存Cache（代理服务器proxy server）：代理服务器缓存用户请求过的原始服务器的内容，这样用户不需要访问原始服务器，就可以满足客户要求（本地访问），快，减少原始服务器请求，降低网络拥塞、网络载荷。
但是代理服务器需要一直更新本地的缓存，条件GET方法：代理服务器向原始服务器请求，内容没换，原始服务器回一个head，not modified，如果内容有更新，再带上body数据。
2.3 FTP
FTP: 文件传输协议，默认端口20。
可以把本地文件上传到服务器，也可以从服务器下载文件，达到信息数据共享的效果。
控制连接与数据连接分开：
连接请求-连接，FTP控制连接-连接完成（服务器主动跟客户端建立数据连接）-在此之上完成用户确认（用户名、口令，明文传输），原语调用-上传下载文件。
FTP需要维护用户状态，是有状态的协议。
命令响应报文、状态码也是ASCII码的形式。
2.4 E-Mail
3个主要组成部分：
用户代理（软件outlook等，代理用户去做一些操作），邮件服务器，简单邮件传输协议SMTP。
使用TCP在客户端和服务器之间传输报文，默认端口号为25。
直接传输，从发送方到接收方服务器。
传输分三个阶段：握手建立连接、传输报文，关闭连接。
命令响应报文都是ASCII码形式，响应报文包含状态码和状态信息，报文必须为7位ASCII码。
报文格式：多媒体邮件扩展MIME multimedia mail extension
POP3协议：邮局协议第三版，Post Office Protocol - Version 3，支持客户端远程管理服务器上的邮件，下载、删除、保留，加上了保密协议加密方式SSL的POP3称为POP3S。
IMAP协议： Internet Mail Access Protocol（交互式邮件存取协议），服务器将每个报文与一个文件夹联系起来，允许用户使用目录来组织报文，允许用户读取报文组件，会话中保留用户状态。
2.5 DNS
DNS (Domain Name System) 域名解析系统，一个基础性的系统，是给应用用的，主要提供域名到IP地址的转换，还可以均衡访问请求。
问题：怎样命名，怎样解析，怎样维护。
分级命名，国家：.cn .jp .us等，类型：.com .edu .gov等；
怎么解析：
互联网名字空间分成一个个区域zone，zone之间互不重叠，每个区域都有一个区域名字服务器Name Server，维护区域内所有的域名和IP的对应关系。
TLD顶级域服务器，上层服务器包含对下层服务器的指针，能够按需求向下查询。
区域名字服务器维护资源记录resource records，维护域名-IP地址的映射关系，位置在Name Server的分布式数据库中。
DNS domain name server：保存资源记录RR的分布式数据库。
RR格式：name，value，type，ttl
DNS大致工作过程：
应用调用解析器resolver；
解析器作为客户 向Name Server发出查询报文（封装在UDP段中）；
Name Server返回响应报文（name/IP）
Local name server 本地名字服务器：
并不严格属于层次结构，顺着树根向上递归查询，计算量大，通过迭代查询解决。
迭代查询iterated queries，查根DNS，没有查二级DNS，二级DNS也会缓存。
2.6 P2P应用
P2P架构：
没有（或极少）一直运行的服务器；
任意端系统都可以直接相互通信；
利用peer的服务能力；
Peer节点间歇性上网，每次IP地址都有可能发生变化。
文件分发：对比C/S模式对比p2p模式：
C/S下载时间：D_c/s >= max{NF / u_s, F / d_min };
P2P下载时间：D_p2p >= max{F / u_s, F / d_min, NF / (u_s + u_i的和) }.
p2p总共只需要一份F就够了，不需要NF，还多出了N个u_i作服务器提供数据下载服务，大大节省了文件分发的耗时，所付出的代价就是管理变得更加困难，但是绝对是利大于弊的模式改进。
C/S管理容易，可扩展性差；
p2p高度动态性，管理难，可扩展性强。
P2P文件共享两大问题：
如何定位所需资源；如何处理对等方peer的加入和离开。
解决方法：
1. 集中式目录：当对等方连接时，告知中心服务器（IP地址、内容）
问题：单点故障、性能瓶颈、侵犯版权
2. 完全分布式：查询泛洪flooding：在已有TCP连接上向所有邻居查询，邻居再向所有邻居查询。节点加入和离开网络都要告知邻居。
问题：要限制泛洪，而且管理困难。
3. 混合体：小范围的集中式目录查询，小范围内用户向组长查询，组长层面上是分布式的。统一哈希值命名，加快搜索速度。
2.7 CDN (Content Delivery Network) 内容分发网络
在应用层形成一个分发网络，解决互联网杀手级应用的内容加速服务。
DASH（Dynamic Adaptive Streaming over HTTP）动态自适应流化服务：
通过域名解析，重定向最近的缓存节点（缓存服务器）。
