4.6万字长文总结计算机网络 &&《计算机网络·自顶向下方法》学习笔记（1-6章）

Posted 2021-10-26 狱典司

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了4.6万字长文总结计算机网络 &&《计算机网络·自顶向下方法》学习笔记（1-6章）相关的知识，希望对你有一定的参考价值。

文章目录

第一章计算机网络和因特网
- 1.1 时延
- 1.2 层次模型
第二章应用层
第三章运输层
第四章数据平面
第五章控制平面
第六章链路层和局域网
计算机网络常用术语中英对照

前言：

大多数的内容都是本人在学习《计算机网络·自顶向下方法》（第七版）一书时做的记录，博客内部分图片来自网络，侵删。
本篇博客可能覆盖面广度不足，但适合结合书本学习用于强化和加深理解。
博客中的“p xxx”意思是《计算机网络·自顶向下方法》（第七版）一书中的页数，更适合结合书本阅览。
如对您有帮助，感谢点赞！收藏！关注！若有错误的地方，也感谢批评指正！
有空就会来更新细化这篇博客，多加点易于理解的图片什么的…

第一章计算机网络和因特网

第一章的内容主要是一些宏观概念和计算，不重点介绍。
推荐看书或看<计算机网络王道考研>系列视频。

ISP（网络服务供应商 Internet Service Provider）

1.1 时延

时延的类型：
（1）处理时延：检查首部和决定将该分组导向何处
（2）排队时延：分组在链路上等待传输
（3）传输时延：也叫注入时延，是将所有的分组的比特推向链路（发射）所需要的时间
（4）传播时延：在链路上传播的时间（从链路的起点到路由器）
时延带宽积
往返时延RTT
利用率：

例题1：

题解：
（1）page50、p25
a： Tprop=d/s= 210^7 / 2.510^8 = 0.08s
故带宽延时积为210^6 x 0.08 = 160000 bit
b：160000 bit
c：带宽时延乘积指的是链路的带宽与传播时延的乘积。结果为比特的数据量，表示在特定时间该网络上的最大数据量。
d：该链路上一个比特宽度为：210^7/160000= 125m ，而足球场长度通常为90-120m，故大于足球场长度。
e：比特宽度表达式推导：d/（RTprop）= d/（Rd/s）= s/R

（2）page50、p27
a：Tprop=d/s= 210^7 / 2.510^8 = 0.08s
故带宽延时积为10^9 x 0.08 = 0.810^8 bit
b：0.810^8 bit
c：s/R=2.5*10^8 / 10^9 = 0.25m（基于上一题得到的公式）

（3）page50、p28
a：T=Ttrans+Tprop=810^ 5 / (210 ^ 6)+210 ^ 7 / 2.510 ^ 8 = 0.4+0.08 = 0.48s（忽略了处理和排队时延）
注意：用于求注入（传输）时延的信道宽度即带宽，与用于求带宽时延积的“带宽”相同，单位为bps（bit/s）
b：Ttrans_分组=410 ^ 4/(210 ^ 6)0.02s , 故T_分组=Ttrans_分组+Tprop=0.1s
发送20个文件的总用时为：19 * T_分组+1 * Ttrans_分组=190.1+0.02=1.92s
C：分组发送时长>连续发送时长。

例题2：

题解：
（4）p47 R19
a：吞吐量的值是其中传输速率最小的链路的传输速率，即该文件传送的吞吐量为500kbps.
b：时间: 8 * 4Mb / 500kbps = 32Mb / 0.5Mbps = 64s
c：当R2减少到100kbps时, R2所处链路就变成了瓶颈链路，故吞吐量为: 100kbps；
传输时间为: 8 * 4Mb / 0.1Mbps = 320s

1.2 层次模型

各类层次模型总结：

例题：
简述五层模型中有哪些层次及其作用？

有应用层、运输层、网络层、链路层、物理层：
a：应用层: 应用层协议用于各个端系统中的应用程序交换信息分组, 该信息分组称为报文.
b：运输层: 运输层的作用是在应用程序端点之间传送应用层报文段. 在因特网中有TCP和UDP两种运输协议, 任一个都能封装并运输应用层报文, 运输层的分组称为报文段.
c：网络层: 网络层负责将运输层的报文段和目的地址封装成数据报, 用于下一层的传输.
d：链路层: 链路层会把网络层的数据报封装成链路层的帧, 并把该帧传递给下一个结点.
e：物理层: 物理层的任务是将链路层每帧中的一个个比特移动到下一个节点,具体会落实到不同的物理媒介(双绞铜线, 光纤等).

第二章应用层

2.1 网络套接字（API）

（1）多数应用程序是由通信进程对组成的，进程对中的两个进程互相发送报文：
一个进程通过软件接口（API）向网络接收报文；（进程是房子，API是门）；

（2）该套接字是建立网络应用程序的可编程接口，因此也称作：
应用程序与网络之间的应用程序编程接口（Application Programming Interface）

（3）API是应用程序进程与运输层协议之间的端口（p58页图）

web服务器用端口号80来标识，邮件服务器进程（使用SMTP协议）用端口号25来标识
TCP提供两种服务：（p61）
（1）面向连接服务——先握手（ACK）后建立全双工链接
（2）可靠数据传输服务—— a.有序、无差错发送 b.请求重传 c.拥塞控制
UDP是一种不提供不必要服务的轻量级运输协议，仅提供最小服务（p62）

无论是TCP还是UDP都没有提供任何加密机制；
SSL（安全层套接字Secure Socke Layer）是提供了安全性服务的加强版TCP

2.2 Web和HTTP

Web的应用层协议是HTTP（超文本传输协议，HyperText Transfer Protocol）；

HTTP由两个程序实现：
（1）客户程序 —— Web浏览器
（2）服务器程序 —— Web服务器

每个URL地址表包括两个部分：（1）主机名（2）路径名
例如：对于URL地址如https://blog.csdn.net/weixin_45067603/article/details，其主机名为https://blog.csdn.net，路径名为：/weixin_45067603/article/details（p64）
HTTP使用TCP作为它的（传输层的）支撑运输协议；
如API中描述的，Client端的套接字是客户进程与TCP链接之间的门，Server端同理，
都从它们的套接字接口API发送HTTP请求和接收HTTP响应报文
注意：HTTP中，Server向客户发送被请求的文件，而不存储关于用户的任何信息状态，故HTTP被称为“无状态协议”
TCP三次握手的总响应时间：（p67）
粗略为两个RTT加上服务器服务器传输html文件的时间
HTTP请求报文和响应报文（p67~p69）
参考博客：抓包简要分析HTTP协议

Web缓存器（Web cache），也叫代理服务器（proxy server）：（p72）
工作原理：
Web缓存器有自己的磁盘存储空间，并存储最近请求过的对象的副本（局部性原理）；
（1）Web浏览器向Web缓存器发送一个HTTP请求并建立一个TCP链接；
（2）Web缓存器检查自身是否存储了被请求对象的副本
（3.1）如果有就发送给Client
（3.2.1）如过没有就向该对象的初始服务器（如www.xxx.edu）请求该对象
（3.2.2）得到该对象后存储（包含修改日期）并转发给Web浏览器即Client
可以看到在Web缓存器的工作过程中，Web缓存器即作为Client端又作为Server端
Web缓存器的作用：
（1）可以大大减少对客户请求的响应时间
（2）从整体上大大减低因特网上的Web流量，从而改善了所有应用的性能

条件GET方法：（p74）

Web缓存器上保存的副本是不是最新的？近期是否被修改过？条件GET方法解决了问题。
形式：请求报文使用GET方法，且请求报文中包含一个”If-Modified-Since：”首部行；
Web Client向proxy cache发送请求，如proxy cache发现了有该请求对象的本地缓存，则向Web server发送一个条件GET请求报文——仅当指定日期之后对请求对象修改过，才重新发送该对象，否则只需回应一个没有请求对象实体的条件GET响应报文。

2.3 因特网中的电子邮件

因特网电子邮件系统：（p76）
3个主要组成部分：
（1）用户代理（user agent）
（2）邮件服务器（mail server）
（3）简单邮件传输协议（SMTP，使用TCP）
每台邮件服务器即运行SMTP的客户端又运行SMTP的服务端：
邮件服务器上包含（1）报文队列（mesege queue）—— 用于发文件
（2）邮箱（mailbox）—— 用于收文件

SMTP的出现早于HTTP，使用25号端口，它限制所有文件的报文体部分（不只是其首部）只能采用简单的7位ASCII码表示，即在使用SMTP传送邮件之前需要将2进制的多媒体数据编码为7位ASCII码，并在传输后解码还原（对比HTTP并不需要此步骤）

一封邮件发送的通常情况：（p77 图2-15）
（1）A调用邮件代理程序（用户代理），提供B的邮件地址，撰写报文，指示发送；
（2）A的用户代理把报文发给A的邮件服务器中的报文队列中；
（3）运行在A邮件服务器上的SMTP客户端发现了报文队列中的这个报文，随即创建一个TCP链接到运行在B邮件服务器上的SMTP服务器；
（4）经历一些初始的SMTP握手，报文从A的邮件服务器上的报文队列中由SMTP的客户端发送到B的邮件服务器；
（5）B的邮件服务器上，SMTP的服务端接收该报文，并将报文放进邮箱中；
（6）B在方便的时候，调用他的用户代理阅读该报文
需要注意的是：
（1）SMTP一般不使用中间邮件服务器发送邮件，即使这俩邮件服务器位于地球的两端；
（2）如果接收方的邮件服务器没有开机，那么发送方要发送的报文将会保存在其自己的邮件服务器中的报文队列中等待做新的尝试。
对比SMTP和HTTP（p79）
持续的SMTP和HTTP都使用持续链接，故两个协议有一些共同特征，然而也存在重要区别：
（1）HTTP主要是一个拉协议（pull protocol）—— 用户从服务器拉取信息；
SMTP基本上是个推协议（push protocol）—— 发送邮件服务器把邮件推向接收邮件服务器；
（2）SMTP要求每个报文采用7比特ASCII码格式，HTTP数据则不受这种限制；
（3）对于一个既包含文本又包含图形（或者是其他媒体类型）的文档：
HTTP把每个对象封装到它自己的HTTP响应报文中；
SMTP则把所有报文对象放在一个报文中；
问题的引入：
因特网电子邮件系统中的用户代理并不能使用SMTP获得报文，因为取报文是一个拉操作，而SMTP是一个推协议。通过引入一个特殊的邮件访问协议来解决这个问题：
（1）POP3 —— 第三版的邮局协议（Post Office Protocal—Version 3）
（2）IMAP —— 因特网邮件访问协议（Internet Mail Access Protocal）
（3）HTTP ——（超文本传输协议，HyperText Transfer Protocol）
POP3 （p81）
因为该协议非常简单，故其功能相当有限。
当用户代理（客户）打开了一个到邮件服务器（服务器）端口110上的TCP连接后，POP3就开始工作，POP3按照三个阶段进行工作：
（1）特许（authorization）：用户代理以明文形式发送用户名和口令来鉴别用户
（2）事务处理：用户代理取回报文，还可以对报文做删除标记，取消删除标记，以及获取邮件的统计信息；
（3）更新：出现在客户发出quit命令后，邮件服务器删除那些被标记为删除的报文
IMAP（p82）
POP3无法为客户创建远程文件夹并为报文指派文件夹，只能将报文下载到本地文件；
为了解决这个问题，因特网邮件访问协议IMAP应运而生。
基于Web的电子邮件（p82-83）
用户代理就是普通的浏览器，用户和他远程邮箱之间的的通信则通过HTTP进行。
这种模式下：
（1）同一个用户的用户代理（浏览器）与邮件服务器之间的发与接通过HTTP（而非发靠SMTP，收靠IMAP、POP3）
（2）但是不同用户之间的邮件服务器发送和接收邮件仍用的是SMTP

2.4 DNS（域名系统 — Domain Name System）

DNS（域名系统 — Domain Name System）：因特网的目录服务（p83）

人类更喜欢记忆主机名，而路由器更喜欢定长的、有结构层次的IP地址，DNS应运而生：
DNS能进行主机名到IP地址转换的目录服务。

一、DSN是：
（1）一个由分层的DNS服务器（DNS server）实现的分布式数据库
（2）一个使得主机能够查询分布式数据库的应用协议
DNS服务器通常是运行BIND软件的UNIX机器；
DNS协议运行在UDP之上，使用53号端口；
DNS通常使用UDP。
除了主机名到IP地址的转换，DNS还提供了以下非常重要的服务：（84）
（1）主机别名（host aliasing） —— 对应规范主机名（canonical hostname）
（2）邮件服务器别名（mail server aliasing）—— 对应邮件服务器的规范主机名
注：MX记录允许一个邮件服务器和Web服务器使用相同（别名化）的主机名；
（3）负载分配（load distribution）
DNS的服务由分布在全球的大量DNS服务器以及定义了DNS服务器与查询主机通信方式的应用层协议组成。
二、RR（资源记录 Resource Record）（p89）
RR提供了主机名到IP地址的映射；
RR是一个包含了以下字段的四元组：（Name，Value，Type，TTL）

TTL（Time To Live）：该记录的生存时间，它决定了给了该记录应当从缓存中删除的时间；
而Name和Value的值取决于Type;

RR四元组中Type的常见类型：

（1）A ： Name是主机名，Value是该主机对应的IP地址 —— 一条A类型的资源记录提供了标准主机名到IP地址的映射；
例：（relay1.bar.foo.com, 145.37.93.126, A,TTL）

（2）NS ：Name是个域（如foo.com），Value是一个权威DNS服务器的主机名，该权威DNS服务器知道如何获得该域（即Name）中主机的IP地址 —— 一条NS类型的RR用于沿着查询链路来路由DNS查询;
例：（foo.com, dns.foo.com, NS, TTL）

（3）CNAME：Name为某主机的别名，Value为对应的规范主机名 —— 一条CNAME类型的RR能够提供一个主机名对应的规范主机名；
例：（foo.com, relay1.bar.foo.com, CNAME, TTL）

（4）MX： Name为某邮件服务器的别名，Value对应其邮件服务器的规范主机名 —— 一条MX类型的RR能够提供一个邮件服务器对应的规范主机名；
例：（foo.com, mail.bar.foo.com, MX, TTL）

（5）PTR：反向解析 —— 从IP到主机名

DNS通常是由其他应用层协议使用的，包括HTTP，SMTP，FTP；
但是DNS本身也属于应用层协议，因为它是使用C/S模式（客户-服务器模式）运行在通信的端系统之间的。
三、一个主机通过DNS获取指定主机名对应的IP地址并发起HTTP的TCP连接的过程：
（1）浏览器截取URL中的主机名字段，发送给DNS应用的客户端；
（2）DNS客户端向DNS服务器发送一个包含主机名的请求；
（3）DNS客户端收到来自DNS服务器发出的回答报文，该报文中包含对应请求主机名对应的IP地址；
（4）浏览器接收到来自DNS的该IP地址
（5）浏览器向位于该IP地址80端口的HTTP服务器进程发起一个TCP连接

可以看到DNS的使用带来了额外的时延，但通过DNS缓存技术和其分布式、层次数据库的特性，想获得的IP地址通常就缓存在“附近的”DNS服务器中，减少了DNS的网络流量和DNS的平均时延。

四、DNS的设计模式

（1）因特网只是用一个DNS服务器：
问题包括：单点故障、通信容量、远距离的集中式数据库、维护

（2）分布式、层次数据库
当今的DNS设计模式

五、分布式、层次数据库
为了处理拓展性的问题，DNS使用了大量以层次方式组织并分布于全球范围的大量DNS服务器。没有一台DNS服务器拥有因特网上所有主机的映射，相反，这些映射分布于所有的DNS服务器上。
DNS服务器的3中主要类型：（p86）
（1）根DNS服务器
全球有400多个根DNS服务器，由13个组织管理；
（2）TLD，顶级域DNS服务器（Top-Level Domain）
常见的顶级域名：com,org,net,edu,gov ; 国家顶级域名：uk,fr,jp,ca；
（3）权威DNS服务器
在因特网上具有公共可访问主机的组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射成IP地址；
严格来说不属于上述DNS服务器层次结构的一类很重要的DNS服务器
——本地DNS服务器（local DNS server）;
每个ISP（如一个居民区的ISP或一个机构的ISP）都有有一台本地DNS服务器；
当主机发出DNS请求时，该请求先被发往本地DNS服务器，它起着代理的作用，并将请求转发到DNS服务器层次结构中。
在不考虑DNS缓存的角度上，假定一个DNS客户要获取www.amazon.com的IP地址，它需要经历以下层次：
（1）与根服务器之一联系，它将返回顶级域名com的TLD服务器的IP地址；
（2）与这些TLD服务器之一联系，它将返回amazon.com的权威服务器的IP地址；
（3）最后，与amazon.com的权威服务器之一联系，获取www.amazon.com的IP地址。
六、DNS的迭代与递归查询（p87~88）
理论上任何DNS查询既可以是迭代的也可以是递归的，但实践中：
（1）从请求主机到本地DNS服务器的查询是递归的——以自己的名义请求获得映射
（2）其余的查询都是迭代的——所有的回答都直接返回给本地DNS服务器
七、DNS缓存（p89）
当某DNS服务器接收到一个DNS回答，它能将映射缓存在本地存储器中。
但这种缓存并不是永久的，DNS服务器在一段时间后（通常为两天）将丢弃缓存信息。
因为有了缓存除了少数DNS查询以外，根服务器都被绕过了（DNS服务器也可以缓存TLD服务器的IP地址）。
八、DNS报文（p90）

2.5 P2P分发文件（p92~95）

在P2P文件分发中，每个对等方能够向任何其他对等放重新分发它已经收到的该文件的任何部分，从而再分发过程中协助该服务器。

算法公式见P95。

P2P文件分发

客户-服务器体系：极大的依赖与总是打开的基础设施服务器
p2p体系：对总是打开的基础设施有着最小（甚至没有）的依赖

P2P文件分发中，每个对等方能够向任何其他对等方重新分发他已经接收到的该文件的任何部分，从而从分发过程中协助该服务器
目前最流行的P2P文件分发协议是BitTorrent

P2P体系结构的扩展性

传统的客户-服务器体系中，文件分发时间d会随着客户数量（接收方）的增加而线性增加。比如，服务器要向客户发送一个大小为f的文件。如果接收对等方增加了1000倍，则完全发送的时间也会增加1000倍。
但是P2P体系结构不一样。它的最小分发时间总是小雨客户-服务器体系结构的。而且分发时间也并不会随着客户数的增多而线性增长的，而是增长速度逐渐放缓，最终接近于一个极限。这是由于P2P体系结构的对等接收方在接收文件的同时，也向其他对等的接收方发送自己接受到的一部分。这就意味着，在对等方（客户方）也成为了发送方的一部分，随着客户数量的上升，可用于发送文件的资源也增加了！这就是P2P体系的自拓展性：对等方除了是接收文件的比特消费者，也是重新分发者（比特贡献者）。

2.6 内容分发网

CDN的全称是Content Delivery Network，即内容分发网络。

其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络”边缘”，使用户可以就近取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度。

其基本思路就是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳。

通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，cdn系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。

从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因，解决用户访问网站的响应速度慢的根本原因。

第三章运输层

3.1 概述和运输层服务（p121）

概述
运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信功能。

运输层协议是在端系统中而不是路由器中实现的
注意区分运输层和网络层的功能（结合下层为上层服务的概念）
（1）运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信功能。
（2）网络层提供了不同主机之间的逻辑通信

信息单位/运输层分组为 —— 报文段（segement）
（1）将应用层报文划分成较小的块，并为每个块加上一个运输层首部以生成运输层报文段；
（2）在发送端系统中，运输层将这些报文段传递给网络层，网络层将其封装成网络层分组（即数据报）并向目的地发送；
（3）在接收端系统中，网络层从数据报中提取运输层报文段，并将该报文段向上交给运输层，运输层接着处理接收到的报文段，使该报文段中的数据为接收应用进程使用。

IP网际协议概述（属于网络层）
IP的模型是一种尽力而为交付的服务，它不确保报文段的按序交付，不确保报文段中数据的完整性，故是一种不可靠服务。
TCP / UDP概述
（1）TCP提供了一种可靠的，面向连接的服务（提供可靠数据传输和拥塞控制）
（2）UDP提供的则是不可靠的，无连接的服务
如第二章提到的，应用程序开发人员在生成套接字（API）时必须指定是选择TCP还是UDP（选择为应用程序服务（提供支撑）的运输层协议）
多路复用与多路分解
TCP和UDP最基本的责任是：
将两个端系统之间IP的交付 -->拓展为–> 运行在不同端系统上的两个进程之间的交付服务。
将主机间交付扩展到进程间交付被称为：运输层的多路复用与多路分解

3.2 多路复用与多路分解（p125）

将主机间交付扩展到进程间交付被称为：运输层的多路复用与多路分解

运输层与套接字（socket）的联系:
（1）一个进程（作为网络应用的一部分）可能有一个或多个套接字，它相当于网络向进程传输数据和从进程向网络传递数据的门户；
（2）接收主机的运输层并没有直接将报文段中的数据交付给进程，而是将数据交给了中间的套接字。
需要注意的是：
连接套接字与进程之间并非总是一一对应的关系，事实上当今高性能的Web服务器通常只是用一个进程，但是为每个客户连接创建一个具有新连接套接字的新线程，对于这样一台服务器，任何给定时间内都可能有（具有不同标识的）许多套接字连接到相同进程。
多路分解与多路复用的工作：
（1）多路分解（向上交付）：
将运输层报文段中的数据交付给正确的套接字（同一时刻，接收主机上可能有多个套接字）；
（2）多路复用（向下交付）：
在源主机从套接字中收集数据块，并为每个数据块封装上首部信息以生成报文段，而后将报文段传递到网络层。

端口号：
端口号是一个16bit的数，其大小在0 ~ 65535之间；
周知端口号：0 ~ 1023的端口号是受限的，它们保留给周知应用层协议来使用 —— 如HTTP使用80端口，DNS使用53端口，FTP使用21端口，SMTP使用25端口等。

当我们开发一个应用程序时，必须为其分配端口号
运输层的每个报文段中都包含（但不限于）：
（1）源端口号（16bit）：套接字socket的唯一标识符；
（2）目的端口号：指示该报文段要交付到的套接字（的唯一标识符）

无连接（UDP） / 面向连接（TCP）的多路复用与多路分解

（1）一个UDP套接字由一个二元组标识：（目的IP地址，目的端口号）
注： DNS一般都基于UDP；
（2）一个TCP套接字由一个四元组标识：（源IP地址，源端口号，目的IP地址，目的端口号）
注：HTTP、FTP、SMTP基于TCP。

3.3 无连接运输： UDP（p130）

为什么UDP被称为无连接的？

因为在使用UDP时，在发送报文段之前，发送方和接收方的运输层实体之间并没有握手。
由[RFC768]定义的UDP只是做了运输层协议能做的做少的工作，除了复用/分解功能及少量的差错检测之外，它几乎没有对IP增加别的东西。

既然TCP比UDP可靠，为什么开发人员宁愿在UDP上构建应用而不是在TCP上？

（1）UDP对于发送什么数据以及何时发送数据的（应用层）控制更为精确：

采用UDP时，只要进程将数据传给UDP，UDP就会将此数据打包进报文段并立即通过端口（连接套接字）传递给网络层；对比来看，TCP的拥塞控制机制功能不考虑可靠交付需要多长时间，这样的机制就使得如因特网电话、视频会议之类的实时应用性能变差。
实际中，实时应用通常要求最小的发送速率（容易产生拥塞），不希望过分的延迟报文段的传送，并且能够容忍一些数据丢失。这些应用可以使用UDP作为其运输层支撑协议，超出UDP服务（交付服务）的额外功能可作为应用的一部分在应用层完成。

（2）无需建立连接：

TCP在开始数据传输之前要在不同端系统的运输层实体之间进行三次握手以建立连接，这样的动作回产生时延，而UDP则不会引入建立连接的时延 —— 这是DNS运行在UDP而非TCP上的原因之一。
HTTP使用TCP而不是UDP，因为对于具有文本数据的Web网页来说，可靠性是至关重要的。另一方面，用于谷歌的Chrome浏览器中的QUIC协议（快速UDP因特网连接）将UDP作为其支撑运输层协议，并在应用层协议中实现了可靠性。

（3）无连接状态：

TCP需要在端系统中维护连接状态 —— 包括接受和发送缓存、拥塞控制以及序号与确认号的参数。对比来看，UDP不维护连接状态，也不跟踪这些参数。
因此应用程序运行在UDP而不是TCP上的特定应用服务器往往能支持更多的活跃用户。

（4）分组首部开销小：
每个TCP报文段都有20字节的首部开销，而UDP仅有8字节的开销。

UDP中缺乏拥塞控制机制，如果每个人都启动流式高比特率视频而不使用任何拥塞控制的话，路由器中就会存在大量的分组一处，以至于丢包率大大提高，这就引发了TCP的拥塞控制机制，TCP主动降低数据发送速率，基于TCP的应用建立的对话将会被“挤垮”！！！
这是一个潜在的严重问题。很多研究人员已经提出了一些机制，以促使所有的数据源（包括UDP源）执行自适应的拥塞控制
UDP的报文结构
（1）首部：共8个字节 —— 包含四个字段，每个字段2个字节（16bit）
（源端口号，目的端口号，长度(首部+数据)，校验和）
（2）应用数据（报文）
接收方使用校验和（checksum）来检验在该报文段中是否出现了差错。
UDP校验和（p133）

关于UDP包的分析可以查看这篇博客：抓包简要分析TCP、UDP协议

3.4 可靠数据传输原理（p134）

可靠传输协议（rdt）

简要总结rdt（可靠传输协议）在各版本升级中增加了哪些机制（p135~142）

A.从rdt1.0到rdt2.0
rdt1.0基于底层信道完全可靠的假设，且假定接收方接收数据的速率和发送方发送数据的速率同步，不会出现差错，即接收端无需反馈任何信息给发送方。接收方和发送方的FSM（有限状态机）都只有一种状态。

rdt2.0则基于底层信道实际模型下分组中的比特可能受损的情况考虑。故增添了以下机制：

（1）差错检测：使接收方检测何时出了差错;

（2）接收方反馈：让接收方提供明确的反馈信息给发送方以便让发送方了解接收方的情况（即此时分组是否被正确接收），故接收方需向发送方回送一个bit长的ACK（肯定确认）和NAK（否定确认）分组以实现反馈;
注：NAK只针对包受损的情况，不针对丢包的情况！

（3）重传：接收方接收到有差错的分组时，发送方将重传该分组。
以上三种机制是ARQ（自动请求重传）协议的重要组成部分;

（4）停等协议：在收到接收方的反馈之前发送方不再发送任何数据。
发送方有两种FSM状态而接受方仍只有一种状态。

B.从rdt2.0到rdt2.1
rdt2.1在基于rdt2.0的基础上考虑了ACK或NAK受损的情况。故增添了以下机制：
在数据分组（segement）中添加一新字段，让发送方对其数据分组编号，即将发送数据分组的序号放在该字段（对于停等协议这种简单情况，往往一个bit就足够——只有0和1），于是接收端只需检查序号即可确定是否需要重传，接收方可以知道发送方是否在重传前一个分组或是在发送一个新的分组。
rdt2.1的接收方和发送方的FSM状态都是rdt2.0的两倍。

rdt2.1的ACK不需要表明1bit的序号位，这份工作由NAK完成！

C.从rdt2.1到rdt2.2
rdt2.2是在有比特差错信道上实现的一个无NAK的可靠数据传输协议。rdt2.2和2.1的细微变化在于，接收方此时必须包括由一个ACK报文所确认的分组序号。

rdt2.0取消了NAK，将1bit序号从NAK转移到了ACK上！

D.从rdt2.2到rdt3.0
rdt3.0假定除了比特受损之外，底层信道还会丢包。为了实现基于时间的重传机制，加入了倒计数定时器。
因为分组序号在0和1之间交替，rdt3.0有时被称为比特交替协议。

倒计数定时器（countdown timer）的类型：
（1）time out（饱和，延时）
（2）persistent（坚持）
（3）keep live（保活）
（4）TIME_WAIT（等待）
流水线可靠数据传输协议（p143）
rdt3.0是一个功能正确的协议，但是其性能问题的核心在于其停等协议限制了底层网络硬件所提供的能力。
流水线技术需做的update：
（1）增加序号范围
（2）接收方和发送方有能力缓存多个分组
（3）恢复差错：回退N步（GBN，Go-Back-N）和选择重传（SR，Selective Repeat）
一个分组的序号通常存放在数据分组首部的一个固定长度的字段中。如rdt3.0的序号
[0，1]，序号字段的大小为1bit。
在流水线可靠传输数据协议中，分组序号字段的大小为K bit的话，则该序号的范围为
[0，2^k - 1]。
承上，GBN的窗口长度最大为：2^k -1
SR的窗口长度最大为：2^(k-1)
回退N步（GBN，Go-Back-N）—— 累计确认
也常被称为滑动窗口协议。
（看p145，理解图3-19；理解p147图3-22）
为什么说GBK是累计确认的？
因为接收方一次交付给上层仅一个分组（而不是多个），如果分组k已经交付，那么表示所有序号比k小的分组也已经交付。

分析GBN中发送方和接收方的行为：

发送方：
（1）响应上层的调用：
当上层调用rdt_send()时，发送方首先检查发送窗口是否已满；
A. 若未满（即已发送但未确定的分组数<N），则产生一个分组并将其发送，并更新变量；B. 若满，反馈，上层等一会再尝试（但在实际情况中，发送方更可能缓存这些数据或者使用同步信号量(类似于生产者消费者模型)）；
（2）响应收到一个携带序号k的ACK的事件：
若k即为上一次发送的分组序号n——更新滑动窗口变量；
若k不是上一次发送的分组序号n——重传序号k~n的所有分组
（3）响应超时事件：
由倒计数定时器辅助实现。若出现超时，发送方重传所有已经发送但是还未被确认的分组。
注：定时器的计时对应于最早已发送但未被确认的分组；
收到最早发出但未被确认的分组的ACK后定时器重启；
若已经没有了已发送但未被确认的分组，定时器停止。

接收方：
响应收到一个序号为n的分组的事件：
a.检查校验和，确认分组没有受损；
b.确认本次接受到的分组是按序的（即上一个接收的分组的序号是n-1）；
A. 若 a&&b 为 TRUE，那么接收方为分组n发送一个ACK，并将分组中的数据上交应用层；
B. 其他情况下，接收方丢弃n号分组，并为n-1号的分组重新发送一个ACK。

选择重传（SR，Selective Repeat）—— 选择确认
GBN协议本身也存在着性能上的问题，尤其是当窗口长度和带宽延时积（以比特为单位的链路的长度）特别长的时候，单个分组的传输错误就会引起大量不必要的重传。

SR协议应运而生，它让发送方仅重传那些它怀疑在接收方出错（受损或丢失）的分组，从而避免了不必要的重传。

SR与GBN的不同（SR的Update）：
（1）SR的接收方：
GBN中，接收方要判断收到的分组是否出错（包括受损和失序），若出粗则一直拒收/丢弃之后发送方发来的分组并一直对前一个有序分组发送ACK；
但SR中，即使某个分组n出错了，接收方仍然接收发送方n之后发来的分组，并将n之后发来的分组暂时缓存且会回应相应的ACK，等待n收到后将n和缓存的分组按序交付。

3.5 面向连接的运输：TCP

TCP三次握手建立连接：
注：前两个报文段不承载“有效载荷”（即应用层数据），第三个报文段可以承载有效载荷。

第1次握手. (Client) –> [SYN] –> (Server)
　　假如Client和Server通讯. 当Client要和Server通信时，Client首先向Server发一个SYN (Synchronize) 标记的包，告诉Server请求建立连接。
　　
第2次握手. (Client) <– [SYN/ACK] <–(Server)
　　接着，Server收到来自Client发来的SYN包后，会发一个对SYN包的确认包(SYN/ACK)给Client，表示对第一个SYN包的确认，并继续握手操作。
　　
第3次握手. (Client) –> [ACK] –> (Server)
　　Client收到来自Server的SYN/ACK 包,Client会再向Server发一个确认包(ACK)，通知Server连接已建立。至此，三次握手完成，一个TCP连接完成。

发送缓存：
（1）发送缓存是TCP发起三次握手期间设置的缓存之一；
（2）客户进程的数据通过连接套接字之后就由TCP控制，TCP会引导这些数据进入发送缓存里，并在TCP方便的时候以报文段的形式发送这些（发送缓存中的）数据；
（3）TCP能从缓存中取出并放入报文段的数据量受限于MSS（Maximum Segement Size）即最大报文段长度。
设置该MSS要保证一个TCP报文段（当封装在一个IP数据报中）加上TCP/IP首部吧长度（通常40字节）要适合单个链路层帧。
MUT（Maximum Transmission Unit）—— 最大传输单元：最大链路层帧长度。

注意：半双工模型中，发送方有TCP发送缓存，接收方有TCP接收缓存！
但实际上TCP是全双工的！

TCP报文段结构（课本p154~155）

TCP报文段由首部+TCP数据部分组成：

源端口号和目的端口号（各16 bit）——用于实现多路分解/复用
序号和确认号（各32 bit）—— 用于实现可靠数据传输服务
首部长度（4 bit，图中为数据偏移）—— 该字段指示了以32bit的字为单位的TCP首部长度；由于TCP首部中选项和填充字段的可变，TCP首部的长度也是可变的。（通常选项字段和填充字段都为空，故TCP首部的典型长度是20 Byte）
标志（flag）字段（6 bit）：
ACK——用于确认字段中的值是有效的
RST、SYN、FIN——用于连接的建立和拆除
ECE、CWR——用于拥塞控制
PSH——被置位时，接收方立刻将数据交给上层
URG——标识紧急数据
接收窗口字段（16 bit）：用于流量控制
校验和字段（16 bit）：用于给接收方检验分组是否存在比特受损
紧急数据指针字段（16 bit）指出紧急数据的最后一个字节
可选与变长的选项（Option）字段（含填充字段，最大4 Byte）——用于发送方和接收方协商MSS（最大报文长度）

往返时间的估计和超时（课本p157~158）
Key：TCP如何估算发送方和接收方之间的往返时间RTT？
大多数TCP的实现为一个已发送但未确认的报文段估计SampleRTT，且绝不为已被重传的报文计算SampleRTT。
一旦获得一个新的SampleRTT，TCP就会更新EstimatedRTT（用于维持SampleRTT均值）：
EstimatedRTT = (1-a)EstimatedRTT + aSampleRTT
注：[RFC6298]中给出的a推荐值是a = 0.125（即1/8）

TCP四次挥手

四次握手用来关闭已建立的TCP连接
　　1. (Client) –> ACK/FIN –> (Server)
　　2. (Client) <– ACK <– (Server)
　　3. (Client) <– ACK/FIN <– (Server)
　　4. (Client) –> ACK –> (Server)
　　

由于TCP连接是双向连接, 因此关闭连接需要在两个方向上做。ACK/FIN 包(ACK 和FIN 标记设为1)通常被认为是FIN(终结)包.然而, 由于连接还没有关闭, FIN包总是打上ACK标记.。

3.6 拥塞控制

原理：
让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率

问题的引出：
1.如何限制发送方的发送速率
2.发送方如何感知拥塞
3.感受到拥塞之后，发送发如何限制其发送速率

问题的分析&解决：

如何限制发送方的发送速率？
Solution：
1.发送方中未被确认的数据量不会超过cwnd（拥塞窗口）与rwnd（接收窗口）中的最小值；注：TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制，在之前我们还讨论过TCP还有一个对端通告的接收窗口(rwnd)用于流量控制。窗口值的大小就代表能够发送出去的但还没有收到ACK的最大数据报文段，
2.为了关注拥塞控制（与流量控制形成对比），假设TCP接收缓存足够大，则可以忽略接收窗口的限制，使得发送方中未被确认的数据量仅仅受限于cwnd，且假设发送发一直发送数据；注:TCP连接的每一端都是由一个接收缓存、一个发送缓存和几个变量（rwnd就是其中之一）组成
3.上一假设将未被发送的数据量约束于cwnd，间接地就将发送方的发送速率约束于cwnd：
发送方的发送速率 = cwnd/RTT(字节/秒)；至此成功解决问题。

发送方如何感知拥塞？
Solution：
1.当出连接路径上现过度拥堵时，该路径上路由器的缓存会溢出，引起一个数据报（包含一个TCP报文段）被丢弃，随之引起发送发的丢包事件；

2.TCP发送方的“丢包事件”被定义为 —— 出现超时；
·发送方收到来自接收方的3个冗余ACK；
注：重复的ACK应有4个，包含1个初始ACK和3个冗余ACK

3.出现丢包事件，则意味拥塞；至此成功解决问题
注：因为TCP使用确认来触发（或计时）增大cwnd长度，故TCP被称为自计时（self-clocking）的

感受到拥塞之后，发送发如何限制其发送速率？
TCP调节其传输速率的策略是增加其速率以响应到达的ACK，而丢包事件指示路径拥塞，出故现丢包事件后减小传输速率。

TCP拥塞控制算法包含的三个主要部分：
慢启动、拥塞避免、快速恢复

各部分的内容：
· 慢启动：
1.TCP连接初始，cwnd初始值设置为一个MSS，则初始发送速率=MSS/RTT;
例如：MSS=500Btye，RTT=20ms，则初始发送速率=20kbps
2.此后每接当传输的报文段首次被确认，MSS翻倍，即以指数型增长（2^(n-1) * MSS）；
！慢启动有以下三种结束方式：
1.结束指数增长的时刻：当发生一个由超时引起的丢包事件，TCP做两个动作：
①将ssthresh（阈值）记为当前cwnd的1/2;
②将cwnd置为1（MSS）并重新开始慢启动过程；
2.当cwnd在指数型连续增长的过程中等于了阈值，结束慢启动，TCP转移到拥塞避免模式；
3.若检测到三个冗余的ACK，TCP执行一种快速重传并进入快速恢复状态。

·拥塞避免：
1.进入拥塞避免状态，则意味着cwnd的值达到了上一次拥塞时的cwnd值的一半（即阈值）
2.继续翻倍增长实在鲁莽，故采用保守的增长方式（线性增长）：TCP发送方不论何时收到一个新的确认，cwnd都只相应地增加一个MSS；
*以下两种情况结束拥塞避免模式下的线性增长：
1.出现超时的情况下，拥塞避免的行为与慢启动相同，将ssthresh（阈值）更新为当前cwnd的1/2，并将cwnd置为1（MSS）
2.出现三个冗余ACK的情况下：①为了更好的计量结果，三个冗余ACK也要计入MSS；
②ssthresh（阈值）更新为当前cwnd值的一半；
③进入快速恢复状态。

·快速恢复：
理解：快速恢复不涉及连续增长，只是一个cwnd值的变化，根据引起丢包的两种不同情况分别切入慢启动模式或拥塞控制模式。
1.当收到来自“引起TCP进入快速恢复模式的缺失报文段”的ACK时：
①cwnd降低为当前cwnd的1/2;
②依据引起TCP进入快速恢复模式的缺失报文段，cwnd增加（该缺失报文段的冗余ACK个数，一般为3）*MSS；
③进入拥塞避免状态。

2.当出现超时事件引起的丢包时：
①执行如同在慢启动和拥塞避免中相同的动作（更新阈值为cwnd的一半，cwnd置1）；
②迁移到慢启动状态。

注：
1.TCP Tahoe（早期TCP）：不论丢包是由超时还是3个冗余ACK引起的，都无条件的将cwnd置1并进入慢启动阶段；
2.TCP Reno（较新版本）：综合了快速恢复。
实例：

根据以上理解，可以得知：
A.
①若丢包由超时事件引起，则快速回复和拥塞避免中cwnd增长相同，即更新阈值为cwnd的一半，cwnd置1；
②若是由三个冗余ACK引起的丢包事件，快速恢复中cwnd的增长为：
cwnd降低为当前cwnd的1/2，并依据引起TCP进入快速恢复模式的缺失报文段，cwnd增加（该缺失报文段的冗余ACK个数，一般为3）*MSS；而在没有发生拥塞的情况下，拥塞避免的增长：保守的增长方式（线性增长）：TCP发送方不论何时收到一个新的确认，cwnd都只相应地增加一个MSS；

B.
快恢复【快】在：当收到来自“引起TCP进入快速恢复模式的缺失报文段”的ACK时，cwnd不必置1，而是将cwnd降低为当前cwnd的1/2，再依据引起TCP进入快速恢复模式的缺失报文段，令cwnd增加（该缺失报文段的冗余ACK个数，一般为3）*MSS后直接进入拥塞避免状态。

如综合了快速恢复的TCP Reno在遇到三个冗余ACK引起的丢包时，不必像早期的TCP Tahoe那样将cwnd置1并进入慢启动阶段，而是跳过慢启动阶段直接进入拥塞避免状态。

例题：
《计算机网络·自顶向下方法》（第七版）Page.193–Problem10

答案：
C.是根据三个冗余ACK检测来的；因为TCP跳过了慢启动而直接进入了拥塞避免，且第17轮传输的cwdn值约等于阈值(42/2=21)+(缺失报文段的冗余ACK数3)=24MSS，得证；
D.是根据超时检测出来的；因为第23轮及之后传输中TCP进入了慢启动模式，cwnd置1且在cwnd值未超过阈值（约等于29/2=14.5）时保持指数型增长，得证；
E.由TCP从慢启动模式转入拥塞避免模式时的cwnd值可知：在第一个传输轮回里，阈值ssthresh为35-3=32；
F.第18轮传输的阈值ssthresh为42/2=21;
G.同理，阈值为：（25+4）/ 2 = 14.5；
H.第一轮传输的慢启动共传输了1+2+4+8+16+32=63个报文段，慢启动进入拥塞避免是在第6轮传输，6+（70-63）=13，故在第13轮传输中发送第70个报文段；
I.慢启动状态下，若检测到三个冗余的ACK，TCP执行一种快速重传并进入快速恢复状态，故cwnd为8/2+3=7,阈值为8/2=4;
J.第16轮&#x