计算机网络---自顶向下方法

应用层

HTTP协议

用户和服务器的交互—-cookie

cookie技术有四个组件：

• 在HTTP响应报文中的一个cookie首部行；
• 在HTTP请求报文中的一个cookie首部行；
• 在用户端系统中保留一个cookie文件，并由用户的浏览器进行管理；
• 位于Web站点的一个后台数据库；

cookie可以在无状态的HTTP之上建立一个用户会话层；

Web缓存

Web缓存也叫代理服务器，它是能代表初始Web服务器来满足HTTP请求的网络实体；
可以配置用户的浏览器，使得用户的所有HTTP请求首先指向Web缓存器；

安装Web缓存的原因：

• 其可以大大减少对客户请求的响应时间；
• 其能够大大减少一个机构的接入链路到因特网的通信量；

Web缓存器能从整体上大大减少因特网上的Web流量，从而改善了所有应用的性能；

通过使用内容分发网络（CDN），Web缓存器正在因特网中发挥着越来越重要的作用；

文件传输协议—-FTP

FTP使用两条并行的TCP连接来传输文件，一个是控制连接，一个是数据连接。控制连接用于在两个主机之间传输控制信息，数据连接用于实际的发送一个文件。

对于FTP传输而言，控制连接贯穿了整个用户会话期间，但是对会话中的每一次文件传输都需要建立一个新的数据连接（数据连接是非持续的）；

邮件传输

邮件发送过程：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中；

SMTP是因特网电子邮件中的主要的应用层协议，其使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件；

SMTP与HTTP对比：

• HTTP主要是一个拉协议，TCP连接是由想接收文件的机器发起的；
  SMTP基本上是一个推协议，TCP连接是由发送该文件的机器发起的；
• SMTP要求每个报文使用7比特的ASCII码格式，HTTP不受这种限制；
• 对于既包含文本又包含图形的文档，HTTP把每个对象封装到自己的HTTP响应报文段，SMTP则把所有报文对象放在一个报文之中；

DNS

域名系统（DNS）是：

• 一个由分层的DNS服务器实现的分布式数据库；
• 一个使得主机能够查询分布式数据库的应用层协议；

除了进行主机名到IP地址的转换外，DNS还提供了一些重要的服务：
1）主机别名
2）邮件服务器别名
3）负载分配

所有的DNS请求和回答报文使用UDP数据报经端口53发送；

DNS服务器的结构：

• 分布式，层次数据库：
  
  • 根服务器
  • 顶级域名服务器
  • 权威DNS服务器
  • 本地DNS服务器（并不包含在以上三层结构中）
• DNS缓存
  
  • 在一个请求链中，当某DNS服务器接收到一个DNS回答时，它能将该回答中的信息缓存在本地存储器中；
  • 本地DNS服务器也能缓存TLD服务器的IP地址，因而允许本地DNS绕过查询链中的根DNS服务器；

P2P应用

使用P2P体系结构，对总是打开的基础设施服务器有最小的（或者没有）依赖，与之相反，成对间歇连接的主机（称为对等方）彼此直接通信；

应用：

• 单个源向大量对等方分发一个文件；
  
  • 对等方除了是比特的消费者还是它们的重新分发者；
• 分布在大型对等方社区中的数据库；—–（分布式散列表）

运输层

TCP的拥塞控制与其说是提供给调用它的应用程序的服务，不如说是一种提供给整个因特网的服务，TCP的拥塞控制防止任何一条TCP连接用过多的流量来淹没主机之间的链路和交换设备；
TCP力求为每个通过一条拥塞链路的连接平等的共享网络连接带宽；

UDP

UDP只是做了运输协议能够做的最少工作，除了复用/分解功能以及少量差错检测外，它几乎没有对IP增加别的东西；

DNS是使用UDP的应用层协议的一个例子；

有许多应用适合UDP，原因如下：

• 关于何时、发送什么数据的应用层控制更为精细；
  TCP的拥塞控制有时候会遏制发送方，对于一些实施应用通常要求最小的发送速率，不希望过分的延迟报文段的发送，且容忍一些数据丢失；

• 无需建立连接；
  UDP不会引入建立连接的时延，HTTP使用TCP而不是UDP主要是因为对于文本数据的Web网页来说，可靠性很重要，但是，HTTP的TCP连接建立时延对于与下载Web文档的时延来说是一个重要因素；

• 无连接状态；
  TCP需要在端系统中维护连接状态，此连接状态包括接收和发送缓存，拥塞控制参数，以及序号与确认号的参数，UDP不需要，可以支持更多的活跃用户；

• 分组首部开销小。TCP报文段需要20bytes，UDP仅需要8bytes；

UDP中缺乏拥塞控制能够导致UDP发送方和接收方之间的高丢包率，并挤垮了TCP会话，这是一个潜在问题；

在无法确保逐链路的可靠性，又无法确保内存中的差错检测的情况下，如果端到端数据传输要提供差错检测，UDP必须在端到端基础上在传输层提供差错检测；

UDP应用

UDP可被用于RIP路由选择表的更新，也用于承载网络管理数据（SNMP），DNS；

可靠数据传输原理

服务抽象：数据提供一条可靠的信道进行传输，借助于可靠信道，传输数据比特就不会受到损坏或丢失，且所有数据都能按照其发送顺序进行交付—–>可靠数据传输协议；

基于重传机制的可靠数据传输协议称为—>自动重传协议（ARQ）,其还需要三种功能处理存在比特差错的情况：

• 差错检测；–>差错检测，序号
• 接收方反馈；–>ACK确认
• 重传；—>超时/重传
  
  • 回退N步：累积确认，重传所有已发送但未确认的分组；
  • 选择重选：让发送方仅发送那些它怀疑在接收方出错（丢失或受损）的分组而避免了不必要的重传；

可靠数据传输的机制：

• 检验和：检测一个传输分组中的比特错误；
• 定时器：用于超时/重传一个分组，可能该分组（或其ACK）在信道中丢失或者超时；
• ACK ：确认收到
• 序号/确认号：发送和接收端传送数据流的编号，确认号是累积确认；
• 窗口、流水线：发送方被限制在仅发送那些序号落在同一指定范围内的分组；
• 重传：选择重传

TCP

TCP连接

TCP提供全双工服务，TCP连接是点对点的；

对于“三次握手”：前两个报文段不承载“有效载荷”，也就是不包含应用层数据；而第三个报文段可以承载有效载荷；

TCP的最大报文段长度MSS（不包含TCP报文段首部）根据最初确定的本地发送主机发送的最大链路层帧长度（MTU）来设置；

序号和确认号

序号：该报文段首字节的字节流编号；
确认号：主机希望从对等方收到下一字节的序号，采用累积确认；

收到失序报文段时，可以接收并保留失序的字节，并等待缺失的字节以填补该间隔；

事实上，一条TCP连接的双方均可以随机选择初始序号，这样做可以减少将那些仍在网络中存在的来自两台主机之间的先前已终止的连接的报文段，误以为是后来这两台主机之间新建连接所产生的有效报文段的可能性；

往返时间的估计与超时

1. 估计往返时间

   EstimeatedRTT = (1 - a)EstimeatedRTT + a * SampleRTT

   DevRTT = (1 - b) * DevRTT + b * |SampleRTT -EstimeatedRTT|

2. 设置和管理重传超时间隔

   TimeoutInterval = EstimeatedRTT + 4 * DevRTT

1） TCP在认为报文段或其确认报文段丢失或受损时，TCP会重传这些报文段；
2） TCP在收到一个特定报文段的3个冗余ACK就可作为对后面报文段的一个隐式NAK，从而在超时之前就触发对该报文段的重传；

可靠数据传输

因特网的网络层服务（IP服务）是不可靠的，IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性；

TCP的可靠数据传输服务确保一个进程从其接收缓存中读出的数据流是无损坏，无间隔，非冗余和按序的数据流，即该字节流与连接的另一端发送的字节流完全相同；

TCP发送方的简化：
1） 从上层应用程序接受数据：发送报文段，可能的话启动定时器；
2） 超时：重传引起超时的报文段来相应超时事件，重启定时器；

TCP会重传具有最小序号未被确认的报文段，并增大超时值（2倍），每当定时器的另两个事件（收到上层收据，收到ACK）发生时，超时值会重新设定；  

3） 收到ACK：更新发送方的窗口如有未确认的报文段，重启定时器；

定时器过期很可能是有网络阻塞引起的，即太多的分组到达源与目的之间路径上的一台（或多台）路由器队列中，造成分组丢失或长时间排队时延；

快速重传

超时触发重传存在的问题之一是：超时周期可能相对较长，当一个报文段丢失时，这种长超时周期迫使发送方延迟重传丢失的分组，增加了端到端的时延；

如果TCP发送方接收到对相同数据的3个冗余ACK，它把这当做一种提示，说明跟在这个已被确认过3次的报文段之后的报文段已经丢失，一旦收到3个冗余ACK，TCP就执行快重传，在该报文段的定时器过期之前重传丢失的报文段；

流量控制

如果某应用程序读取数据时相对缓慢，而发送方发送的太多，太快，发送的数据就会很容易的使该连接的接收缓存溢出，应用程序可以提供“流量控制”消除发送方使接收方缓存溢出的可能性；

TCP的发送方可能因为IP网络的拥塞而被遏制，这种形式的发送方控制是“拥塞控制”；

TCP提供让发送方维护一个称为接收窗口的变量来提供流量控制，接收窗口用于给发送方一个指示，该接收方还有多少可用的缓存空间；

LastByteRcvd - LastByteRead <= RevBuffer

rwnd = RevBuffer - [LastByteRcvd - LastByteRead]

LastByteSent -  LastByteAcked <= rwnd 

TCP规范中要求：当主机B的接收窗口为0时，主机A继续发送一个只有一个字节数据的报文段，这些报文段将会被接收方确认，最终缓存将开始清空，并且确认报文里将包含一个非0的rwnd值；

TCP连接管理

TCP连接建立

1. 客户端向服务器端发送一个SYN报文段，随机选择一个初始序号放置在起始的SYN报文段中；
2. 服务器收到客户端的SYN报文段后，为该TCP连接分配TCP缓存和变量，并向该客户的TCP发送允许连接的报文段—SYN-ACK报文段；
   
   1. 在完成三次握手的第三步之前分配这些缓存和变量，使得TCP易于受到称为SYN洪泛的拒绝服务攻击；
3. 在收到SYNACK报文段后，客户也要给该连接分配缓存和变量；
   
   1. 第三个阶段可以在报文段负载中携带客户到服务器的数据；

注意事项：
在第二步如果攻击者发送大量的SYN报文段，而不完成第三次握手的步骤，服务器不断为这些半开连接分配资源，导致服务器的连接资源被消耗殆尽—->SYN洪泛攻击；

通过SYN cookie来处理：
1） 客服端发给服务器端一个SYN报文段时，服务器端不会为该报文段生成一个半开连接，服务器会生成一个初始序列号（由IP和端口号加密cookie）的SYNACK分组，服务器并不记忆该cookie或任何对应于SYN的其他状态信息；
2） 若客户端回复ACK报文段，且服务器生成的cookie + 1等于ACK报文段确认序号，则生成一个全开的连接，至此，连接建立；

源主机向目的主机发送一个TCP SYN报文段，可能出现三种情况：
1） 源主机从目的主机接收到一个TCP SYNACK报文段：正常；
2） 源主机从目的主机接收到一个TCP RST报文段：目标主机没有一个运行在该端口上的进程；
3） 源什么也没收到：SYN报文段被中间的防火墙所阻挡，无法到达目的主机；

拥塞控制原理

丢包一般是当网络变得拥塞时由于路由器缓存溢出引起的，分组重传因此作为网络拥塞的前兆；

1） 当分组的到达速率接近链路容量时，分组经历巨大的排队时延；
2） 发送方必须执行重传以补偿因为缓存溢出而丢弃（丢失）的分组；
3） 发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本；
4） 当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了；