计网协议总结

这篇文章是面试复习时整理的，不建议系统学习时看

网络层

IP地址和硬件地址

物理地址是数据链路层和物理层使用的地址，而IP地址是网络层和以上各层使用的地址，是一种逻辑地址

ARP协议（地址解析协议）

ARP协议的用途是为了从网络层使用的IP地址解析出在数据链路层使用的硬件地址，故有的地方也将其归为数据链路层协议都是可以的

因为在实际网络的链路上传送数据帧时最终还是必须使用该网络的硬件地址，ARP的处理就是在主机ARP高速缓存中存放一个从IP地址到硬件地址的映射表，并且这个映射表还经常动态更新（因为网络上会新增和撤走主机）。每一台主机都设有一个ARP高速缓存（即ARP cache），里面有本局域网上的各主机和路由器的IP地址到硬件地址的映射表，这些都是该主机目前知道的一些地址。
ARP协议工作原理：

1. 主机A首先会在cache中查找是否有该IP地址，如果有，就在cache中查出硬件地址，再把这个硬件地址写入MAC帧，然后通过局域网把该MAC帧发往此硬件地址；如果没有，进行第二步
2. a. ARP进程在本局域网上广播发送一个ARP请求分组
   b. 在本局域网上的所有主机都会收到这个ARP请求分组
   c. 如果主机B的IP地址与ARP请求分组中查询的IP地址一致，就收下这个ARP请求分组，并向主机A发送ARP响应分组，在其中写入自己的硬件地址；由于其他主机都与请求分组中的IP地址不一致，就忽略了
   d. 主机A收到主机B的ARP响应分组后，就在其ARP cache中写入主机B的IP地址到硬件地址的映射
   如下图：
   
   下一次主机A需要给主机B传送消息时就只需要在cache中查找即可，省了广播请求分组这一步，使网络上的通信量大大增加

注意：

1. ARP对保存在cache中的每一个映射地址都设置生存时间，超过生存时间就会清除。假设主机A的ARP cache中有主机B的IP地址与硬件地址，而主机B的网络适配器更换了，原来的硬件地址就找不到主机B了，但是过了一段生存时间，A已经清除了主机B的硬件地址，开始重新广播，就又可以找到B了
2. ARP只能解决同一个局域网上的主机或路由器的IP地址和硬件地址的映射问题

使用ARP的四种典型情况：
以下图为例

1. H1-H2：H1发送ARP请求分组找到目的主机H2的硬件地址
2. H1-H3(H4)：H1发送ARP请求分组，找到路由器R1的硬件地址，然后R1进行下面3和4操作
3. 发送方是路由器（如R1），要把IP数据报转发到与R1连接在同一个网络（网2）上的主机（如H3）。这时R1发送ARP请求分组（在网2广播），找到目的主机H3的硬件地址
4. 发送方是路由器（如R1），要把IP数据报转发到网3上的一台主机（如H4）。H4与R1不是连接在同一个网络上。这时R1发送ARP请求分组（在网2上广播），找到连接在网2上的一个路由器R2的硬件地址。剩下的工作由R2完成
   

IP数据报

IP数据报的格式能够说明IP协议都具有什么功能。在TCP/IP的标准中，各种数据格式常常以32位（即4字节）为单位来描述，下图是IP数据报的完整格式

一个IP数据报由首部和数据两部分组成，首部的前一部分是固定长度，共20字节，是所有IP数据报必须具有的。在首部的固定部分的后面是一些可选字段，其长度是可变的

ICMP报文

ICMP报文分为ICMP差错报文和ICMP询问报文
ICMP报文的前4个字节是统一的格式，共有三个字段：类型、代码和检验和。接着的4个字节的内容与ICMP的类型有关。最后面是数据字段，其长度取决于ICMP的类型。

ICMP差错报文

有四种常用类型：

• 终点不可达：当路由器或主机不能交付数据报时就向源点发送终点不可达报文
• 时间超过：当路由器收到生存时间为零的数据报时，除丢弃该数据报外，还要向源点发送时间超过报文；当终点在预先规定的时间内不能收到一个数据报的全部数据报片时，就把已收到的数据报片都丢弃，并向源点发送时间超过报文
• 参数问题：当路由器或目的主机收到的数据报的首部中有的字段的值不正确时，就丢弃该数据报，并向源点发送参数问题报文
• 改变路由（重定向）：路由器把改变路由报文发送给主机，让主机知道下次应将数据报发送给另外的路由器（可通过更好的路由）

所有的ICMP差错报告报文中的数据字段都具有同样的格式。把收到的需要进行差错报告的IP数据报的首部和数据字段的前8个字节提取出来，作为ICMP报文的数据字段。在加上相应的ICMP差错报告报文的前8个字节，就构成了ICMP差错报告报文，如图

整个ICMP报文作为IP数据报的数据字段发送给源点
不应发送ICMP差错报文的情况：

• 对ICMP差错报告报文
• 对第一个分片的数据报片的所有后续数据报片
• 对具有多播地址的数据报
• 对具有特殊地址(如127.0.0或0.0.0.0)的数据报

ICMP询问报文

• 回送请求和回答：ICMP回送请求报文是由主机或路由器向一个特定的目的主机发出的询问。收到此报文的主机必须给源主机或路由器发送ICMP回送回答报文。这种询问报文用来测试目的站是都可达以及了解有关状态
• 时间戳请求和回答：ICMP时间戳请求报文是请某台主机或路由器回答当前的日期和时间。在ICMP时间戳回答报文中有一个32位的字段，其中写入的整数代表从1900年1月1日起到当前时刻一共多少秒。时间戳请求与回答可用于时钟同步和时间测量

ICMP的应用-PING

ICMP的一个重要应用就是分组网间探测PING，用来测试两台主机之间的连通性。PING使用了ICMP回送请求和回送回答报文。PING是应用层直接使用网络层ICMP的一个例子，没有通过运输层的TCP和UDP

路由选择协议

内部网关协议

在一个自治系统内部使用的路由选择协议，目前这类路由选择协议使用的最多，代表有RIP和OSPF

RIP协议

RIP是内部网关协议中最先得到广泛使用的协议，是一种基于分布式的基于距离向量的路由选择协议。RIP协议要求网络中的每一个路由器都要维护从它自己到其他每一个目的网络的距离记录。RIP协议将距离定义如下：
从一路由器直接连接的网络的距离为1；从一路由器到非直接连接的网络的距离定义为所经过的路由器数加1
例如：

R1–网1：1
R1–网2：1
R1–网3：2
R1–网4：3

RIP允许一条路径最多只能包含15个路由器，距离大于等于16时即为不可达，故RIP只适用于小型互联网
RIP协议的特点：

• 仅和相邻路由器交换信息
• 路由器交换的信息是当前本路由器所知道的全部信息，即自己现在的路由表
• 按固定的时间间隔交换路由信息
• 使用UDP传送

RIP存在的问题：
当网络出现故障时，要经过比较长的时间才能将此信息传送到所有的路由器
即：好消息传播得快，坏消息传播得慢

OSPF协议

OSPF是为克服RIP的缺点开发出来的，最重要特征是使用分布式的链路状态协议
OSPF的三个要点和RIP都不一样：

• 向本自治系统中所有路由器发送信息。这里使用的方法是洪泛法，这就是路由器通过所有输出端口向所有相邻的路由器发送信息。而每一个相邻路由器又再将此信息发往其所有的相邻路由器(但不再发送给刚刚发来信息的那个路由器)。这样，最终整个区域中所有的路由器都得到了这个信息的一个副本。而RIP协议是仅仅向自己相邻的几个路由器发送信息。.
• 发送的信息就是与本路由器相邻的所有路由器的链路状态，但这只是路由器所知道的部分信息。所谓“链路状态”就是说明本路由器都和哪些路由器相邻，以及该链路的“度量”。OSPF 将这个“度量”用来表示费用、距离、时延、带宽，等等。这些都由网络管理人员来决定，因此较为灵活。有时为了方便就称这个度量为“代价”。对于RIP协议，发送的信息是:“到所有网络的距离和下一跳路由器”。
• 只有当链路状态发生变化时，路由器才向所有路由器用洪泛法发送此信息。而不像RIP那样，不管网络拓扑有无发生变化，路由器之间都要定期交换路由表的信息

由于各路由器之间频繁地交换链路状态信息，因此所有的路由器最终都能建立一个链路状态数据库，这个数据库实际上就是全网的拓扑结构图。这个拓扑结构图在全网范围内是一致的(这称为链路状态数据库的同步)。因此，每一个路由器都知道全网共有多少个路由器，以及哪些路由器是相连的，其代价是多少，等等。每一个路由器使用链路状态数据库中的数据，构造出自己的路由表(例如，使Dijkstra 的最短路径路由算法)。RIP协议的每一个路由器虽然知道到所有的网络的距离以及下一跳路由器，但却不知道全网的拓扑结构(只有到了下一跳路由器，才能知道再下一跳应当怎样走)。
OSPF的优点是：更新过程收敛的快，为了使OSPF能够用于规模很大的网络，OSPF将一个自制系统再划分为若干个更小的范围，叫做区域，在一个区域内的路由器最好不超过200个，划分区域可以减少整个网络上的通信量，OSPF直接使用IP数据报传送

外部网关协议

源主机与目的主机处在不同的自制系统中，当数据报传到一个自制系统边界时，就需要使用一种协议将路由选择信息传递到另一个自治系统中，即外部网关协议，代表为BGP-4

运输层

运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最底层，运输层协议和网络层协议的主要区别如图

进程间通信等概念

真正进行通信的实体是在主机中的进程，是这台主机中的一个进程和另一台主机中的一个进程在交换数据，严格地讲，两台主机进行通信就是两台主机的应用进程互相通信，从运输层的角度看，通信的真正端点不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之前的通信。
软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址，端口号只具有本地意义，只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口，两个计算机中的进程要互相通信，不仅必须要知道对方的IP地址，还要知道对方的端口号，用于找到对方的应用进程

上图中，主机A的应用进程AP1和主机B的应用进程AP3通信，与此同时，主机A的应用进程AP2和也主机B的应用进程AP4通信。这就表明运输层有一个很重要的功能——复用和分用。复用指发送方不同的应用进程都可以使用同一个运输层协议传送数据，分用指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。
从上图也可以看出网络层和运输层明显区别。网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信
运输层还要对收到的报文进行差错检测，而在网络层IP数据报首部中的检验和字段只检验首部是否出现差错而不检查数据部分
根据应用进程的不同需求，运输层需要有两种不同的运输协议，面向连接的TCP和无连接的UDP

用户数据报协议UDP

用户数据报协议UDP只在IP的数据报服务之上增加了复用和分用的功能以及差错检测的功能。

特点

UDP的主要特点是:

1. UDP是无连接的，即发送数据之前不需要建立连接(当然，发送数据结束时也没有连接可释放)，因此减少了开销和发送数据之前的时延。
2. UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表(这里面有许多参数)。
3. UDP是面向报文的。如图，发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。这就是说，应用层交给UDP多长的报文，UDP 就照样发送，即一次发送一个报文，在接收方的UDP，对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程。也就是说，UDP一次交付一个完整的报文。因此，应用程序必须选择合适大小的报文。若报文太长，UDP把它交给IP层后，IP 层在传送时可能要进行分片，这会降低IP层的效率。反之，若报文太短，UDP把它交给IP层后，会使IP数据报的首部的相对长度太大，这也降低了IP层的效率。
   
4. UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很多的实时应用(如IP电话、实时视频会议等)要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延。UDP正好适合这种要求。
5. UDP 支持一对一、一对多、多对一和多对多的交互通信。
6. UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。

虽然某些实时应用需要使用没有拥塞控制的UDP，但当很多的源主机同时都向网络发送高速率的实时视频流时，网络就有可能发生拥塞，结果大家都无法正常接收。因此，不使用拥塞控制功能的UDP有可能会引起网络产生严重的拥塞问题。
还有一些使用UDP的实时应用，需要对UDP的不可靠的传输进行适当的改进，以减少数据的丢失。在这种情况下，应用进程本身可以在不影响应用的实时性的前提下，增加一些提高可靠性的措施，如采用前向纠错或重传已丢失的报文。

首部格式

UDP有两个字段：数据字段和首部字段，首部字段只有8个字节，由4个字段组成，每个字段的长度都是两个字节

源端口：源端口号。在需要对方回信时选用，不需要时可用全0
目的端口：目的端口号。这在终点交付报文时必须使用
长度：UDP用户数据报的长度，其最小值是8（首部长度）
检验和：检测UDP用户数据报在传输中是否有错，有错就丢弃

如果接收方UDP发现收到的报文中的目的端口号不正确，就丢弃该报文，并由ICMP发送“端口不可达”差错报文给发送方。
UDP用户数据报首部中检验和的计算方法有些特殊。在计算检验和时，要在UDP用户数据报之前增加12个字节的伪首部。所谓“伪首部”是因为这种伪首部并不是UDP用户数据报真正的首部。只是在计算检验和时，临时添加在UDP用户数据报前面，得到一个临时的UDP用户数据报。检验和就是按照这个临时的UDP用户数据报来计算的。伪首部既不向下传送也不向上递交，仅仅是为了计算检验和

传输控制协议TCP

特点

1. TCP是面向连接的运输层协议。这就是说，应用程序在使用TCP协议之前，必须先建立TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接。也就是说，应用进程之间的通信好像在“打电话”:通话前要先拨号建立连接，通话结束后要挂机释放连接。
2. 每一条TCP连接只能有两个端点， 每一条TCP连接只能是点对点的(一对一)
3. TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复，并且按序到达
4. TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给TCP的缓存后，就可以做自己的事，而TCP在合适的时候把数据发送出去。在接收时，TCP把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
5. 面向字节流。TCP中的“流"指的是流入到进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块(大小不等)，但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义。TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系(例如，发送方应用程序交给发送方的TCP共10 个数据块，但接收方的TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序)。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。当然，接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。如下图
   
   注意，途中的发送应该是双向的，为了方便观察只画出了单向；图中的TCP连接是条虚连接 (也就是逻辑连接)， 而不是一条真正的物理连接。 TCP报文段先要传送到IP层，加上IP首部后，再传送到数据链路层。再加上数据链路层的首部和尾部后，才离开主机发送到物理链路。
   TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节。如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分短一些再传送。如果应用进程一次只发来一个字节，TCP也可以等待积累有足够多的字节后在构成报文段发送出去

连接

每一条TCP连接有两个端点。TCP连接的端点不是主机，不是主机的IP 地址，不是应用进程，也不是运输层的协议端口。TCP连接的端点叫做套接字(socket)或插口。根据RFC 793的定义：端口号拼接到IP地址即构成了套接字。因此，套接字的表示方法是在点分十进制的IP地址后面写上端口号，中间用冒号或逗号隔开。例如，若IP地址是192.3.4.5 而端口号是80，那么得到的套接字就是(192.3.4.5: 80)。即：套接字socket = (IP 地址:端口号)
每一条TCP连接唯一地被通信两端的两个端点(即两个套接字)所确定。即：TCP连接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}
这里IP1和IP2分别是两个端点主机的IP地址，而port, 和port2 分别是两个端点主机中的端口号。TCP连接的两个套接字就是socket1 和socket2。 可见套接字socket 是个很抽象的概念。同一个IP地址可以有多个不同的TCP连接，而同一个端口号也可以出现在多个不同的TCP连接中

停止等待协议

停止等待就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组

1. 无差错情况
   下图(a)是最简单的无差错情况。A发送分组M1，发完就暂停发送，等待B的确认。B收到了M1就向A发送确认。A在收到了对M1的确认后，就再发送下一个分组M2。同样，在收到B对M2的确认后，再发送M3。
2. 出现差错
   下图(b)是分组在传输过程中出现差错的情况。B接收M1时检测出了差错，就丢弃M1，其他什么也不做(不通知A收到有差错的分组)。也可能是M1在传输过程中丢失了，这时B当然什么都不知道。在这两种情况下，B都不会发送任何信息。可靠传输协议是这样设计的：A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。要实现超时重传，就要在每发送完一个分组时设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。其实在下图(a)中，A为每一个已发送的分组都设置了一个超时计时器。但A只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器。为简单起见，这些细节在下图(a)中都省略了。
   这里应注意以下三点。
   第一，A在发送完一个分组后，必须暂时保留已发送的分组的副本(在发生超时重传时使用)。只有在收到相应的确认后才能清除暂时保留的分组副本。
   第二，分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。
   第三，超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。下图(b)中的一段虚线表示如果M1正确到达B同时A也正确收到确认的过程。可见重传时间应设定为比平均往返时间更长一些。显然，如果重传时间设定得很长，那么通信的效率就会很低。但如果重传时间设定得太短，以致产生不必要的重传，就浪费了网络资源。然而，在运输层重传时间的准确设定是非常复杂的，这是因为已发送出的分组到底会经过哪些网络，以及这些网络将会产生多大的时延(这取决于这些网络当时的拥塞情况)，这些都是不确定因素。
   
3. 确认丢失和确认迟到
   下图(a)说明的是另一种情况。B所发送的对M1的确认丢失了。A在设定的超时重传时间内没有收到确认，并无法知道是自己发送的分组出错、丢失，或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M1。现在应注意B的动作。假定B又收到了重传的分组M1。这时应采取两个行动。
   第一，丢弃这个重复的分组M1，不向上层交付。
   第二，向A发送确认。不能认为已经发送过确认就不再发送，因为A之所以重传M1就表示没有收到对M1的确认
   下图(b)也是一种可能出现的情况。传输过程中没有出现差错，但B对分组M1的确认迟到了。A会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。B仍然会收到重复的M1，并且同样要丢弃重复的M1，并重传确认分组。
   通常A最终总是可以收到对所有发出的分组的确认。如果A不断重传分组但总是收不到确认，就说明通信线路太差，不能进行通信。
   使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
   像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest)。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。
   
4. 信道利用率
   停止等待协议优点是简单，但缺点是信道利用率太低

首部格式

TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段。一个TCP报文段分为首部和数据两部分，而TCP的全部功能都体现在它首部中各字段的作用。因此，只有弄清TCP首部各字段的作用才能掌握TCP的工作原理。下面讨论TCP报文段的首部格式。TCP报文段首部的前20个字节是固定的，后面有4n字节是根据需要而增加的选项(n是整数)。因此TCP首部的最小长度是20字节。

首部固定部分各字段的意义如下:

1. 源端口和目的端口：各占2个字节，分别写入源端口号和目的端口号。和前面UDP的分用相似，TCP的分用功能也是通过端口实现的。
2. 序号：占4字节。序号范围是[0, 232- 1], 共232 (即4294 967296)个序号。序号增加到232-1后，下一个序号就又回到0。也就是说，序号使用mod 232运算。TCP是面向字节流的。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号字段值是301, 而携带的数据共有100字节。这就表明：本报文段的数据的第一个字节的序号是301， 最后一个字节的序号是400。显然，下一个报文段(如果还有的话)的数据序号应当从401开始，即下一个报文段的序号字段值应为401。这个字段的名称也叫做“报文段序号”。
3. 确认号：占4字节，是期望收到对方下一个报文段的第一个数据字节的序号。例如，B正确收到了A发送过来的一个报文段，其序号字段值是501，而数据长度是200字节(序号501 ~ 700)，这表明B正确收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701.。请注意，现在的确认号不是501，也不是700，而是701
4. 数据偏移：占4位，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。但应注意，“数据偏移”的单位是32位字(即以4字节长的字为计算单位)。由于4位二进制数能够表示的最大十进制数字是15，因此数据偏移的最大值是60字节，这也是TCP首部的最大长度(即选项长度不能超过40字节)。
5. 保留：占6位，保留为今后使用，但目前应置为0。
   下面6个（6-11）是控制位，用来说明本报文段的性质
6. 紧急URG：当URG=1时，表明紧急指针字段有效。
7. 确认ACK：仅当ACK= 1时确认号字段才有效。当ACK= 0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置1。
8. 推送PSH：当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，TCP就可以使用推送操作。这时，发送方TCP把PSH置1，并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段，就尽快地(即“推送”向前)交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。虽然应用程序可以选择推送操作，但推送操作很少使用。
9. 复位RST：当RST= 1时，表明TCP连接中出现严重差错(如由于主机崩溃或其他原因)，必须释放连接，然后再重新建立运输连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个连接。RST也可称为重建位或重置位。
10. 同步SYN：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。因此，SYN置为1就表示这是一个连接请求或连接接受报文
11. 终止FIN：用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
12. 窗口：窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口），窗口值作为接收方让发送方设置其发送窗口的依据

TCP可靠传输的实现

滑动窗口

现在假定A收到了B发来的确认报文段，其中窗口是20字节，而确认号是31（这表明B期望收到的下一个序号是31，而序号30为止的数据已经收到了）。根据这两个数据，A就构造出自己的发送窗口。

发送窗口表示：在没有收到B确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认前连续发送更多的数据，因而可能获得更高的传输效率。A的发送窗口一定不能超过B的接收窗口数值。发送窗口后沿的后面部分表示已发送且已收到了确认，这些数据不需要保留，发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间
发送窗口前沿通常是不断向前移动，但也有可能不动，有两种情况：一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动
发送窗口前沿也有可能向后收缩，这发生在对方通知的窗口缩小了，但TCP的标准强烈不赞成这么做

流量控制

一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方可能来不及接收，这就会造成数据的丢失，流量控制就是让发送方的发送速率不要太快，让接收方来得及接收
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制
A向B发送数据，在连接建立时，B告诉A：“我的接收窗口rwnd = 400”，则如图

拥塞控制

介绍

在计算机网络中的链路容量（即带宽）、交换节点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种情况叫做拥塞
拥塞控制与流量控制的关系密切，它们之间也存在着一些差别。所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。但TCP连接的端点只要迟迟不能收到对方的确认信息，就猜想在当前网络中的某处很可能发生了拥塞，但这时却无法知道拥塞到底发生在网络的何处，也无法知道发生拥塞的具体原因。(是访问某个服务器的通信量过大?还是在某个地区出现自然灾害?)
相反，流量控制往往是指点对点通信量的控制，是个端到端的问题(接收端控制发送端)。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
但是，实际网络的情况就很不相同了。从下图可看出，随着提供的负载的增大，网络吞吐量的增长速率逐渐减小。也就是说，在网络吞吐量还未达到饱和时，就已经有一部分的输入分组被丢弃了。当网络的吞吐量明显地小于理想的吞吐量时，网络就进入了轻度拥塞的状态。更值得注意的是，当提供的负载达到某一数值时，网络的吞吐量反而随提供的负载的增大而下降，这时网络就进入了拥塞状态。当提供的负载继续增大到某一数值时， 网络的吞吐量就下降到零，网络已无法工作，这就是所谓的死锁。

拥塞控制方法

TCP 进行拥塞控制的算法有四种，即慢开始、拥塞避免、快重传和快恢复
下面讨论的拥塞控制也叫做基于窗口的拥塞控制。为此，发送方维持一个叫做拥塞窗口 cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。
慢开始算法的思路是这样的：当主机开始发送数据时，出于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络，那么就有可能引起网络发生拥塞。经验证明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。
下面用例子说明慢开始算法的原理。请注意，虽然实际上 TCP 是用字节数作为窗ロ大小的单位。但为叙述方便起见，我们用报文段的个数作为窗口大小的单位，这样可以使用较小的数字来阐明拥塞控制的原理。
在一开始发送方先设置 cwnd =1，发送第一个报文段 M1，接收方收到后确认 M1。发送方收到对 M1的确认后，把 cwnd 从1增大到2，于是发送方接着发送 M2和 M3两个报文段。接收方收到后发回对 M2和 M3，的确认。发送方每收到一个对新报文段的确认（重传的不算在内）就使发送方的拥塞窗口加1，因此发送方在收到两个确认后， cwnd 就从2增大到4，并可发送 M4 ~ M7 共4个报文段。因此使用慢开始算法后，每经过一个传输轮次，拥塞窗口 cwnd 就加倍。

这里我们使用了一个名词一传输轮次。 从上图可以看出，一个传输轮次所经历的时间其实就是往返时间RTT (请注意，RTT并非是恒定的数值)。使用“传输轮次”是更加强调：把拥塞窗口cwnd 所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。例如，拥塞窗口cwnd的大小是4个报文段，那么这时的往返时间RTT就是发送方连续发送4个报文段，并收到这4个报文段的确认，总共经历的时间。
注意：慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段(目的是试探一下网络的拥塞情况)，然后再逐渐增大cwnd。这当然比设置大的cwnd值一下子把许多报文段注入到网络中要“慢得多”。这对防止网络出现拥塞是一个非常好的方法。
上图也只是为了说明慢开始的原理。在TCP的实际运行中，发送方只要收到一个对新报文段的确认，其拥塞窗口cwnd就立即加1，并可以立即发送新的报文段，而不需要等这个轮次中所有的确认都收到后再发送新的报文段。
为了防止拥塞窗口 cwnd 增长过大引起网络拥塞，还需要设置一个慢开始门限 ssthresh 状态变量，慢开始门限 ssthresh 的用法如下：
当 cwnd < ssthresh 时，使用上述的慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthrcsh 时，既可使用慢开始算法，也可使用拥塞避免算法。
拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加1，而不是像慢开始阶段那样加倍增长。因此在拥塞避免阶段就有“加法增大” AI的特点。这表明在拥塞避免阶段，拥塞窗口 cwnd 按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
下图用具体例子说明了在拥塞控制的过程中，TCP 的拥塞窗口 cwnd 是怎样变化的。图中的的数字①至⑥是特别要注意的几个点。现假定 TCP 的发送窗口等于拥塞窗口。
当 TCP 连接进行初始化时，把拥塞窗口 cwnd 置为1。为了便于理解，图中的窗口单位不使用字节而使用报文段的个数。在本例中，慢开始门限的初始值设置为16个报文段，即 ssthresh =16。在执行慢开始算法时，发送方每收到一个对新报文段的确认 ACK ，就把拥塞窗口值加1，然后开始下一轮的传输（请注意，下图的横坐标是传输轮次，不是时间）。因此拥塞窗口 cwnd 随着传输轮次按指数规律增长。当拥塞窗口cwnd 增长到慢开始门限值 ssthresh 时（图中的点 ① ，此时拥塞窗口 cwnd =16)，就改为执行拥塞避免算法，拥塞窗口按线性规律增长。但请注意，“拥塞避免”并非完全能够避免了拥塞。“拥塞避免”是说把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

当拥塞窗口 cwnd =24时，网络出现了超时（图中的点②)，发送方判断为网络拥塞。于是调整门限值 ssthresh = cwnd /2=12，同时设置拥塞窗口 cwnd =1，进入慢开始阶段。
按照慢开始算法，发送方每收到一个对新报文段的确认 ACK ，就把拥塞窗口值加1。
当拥塞窗口 cwnd = ssthresh =12时（图中的点 ③ ，这是新的 ssthresh 值），改为执行拥塞避免算法，拥塞窗口按线性规律增大。
当拥塞窗口 cwnd =16时（图中的点 ④ )，出现了一个新的情况，就是发送方一连收到3个对同一个报文段的重复确认（图中记为3-ACK)。
有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口 cwnd 又设置为1，因而降低了传输效率。
采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。如上图所示，接收方收到了 M1 和 M2 后都分别及时发出了确认。现假定接收方没有收到 M3 但却收到了 M4 。本来接收方可以什么都不做。但按照快重传算法，接收方必须立即发送对 M2 的重复确认，以便让发送方及早知道接收方没有收到报文段 M3 。发送方接着发送 M5 和M6。接收方收到后也仍要再次分别发出对 M2 的重复确认。这样，发送方共收到了接收方的4个对 M2 的确认，其中后3个都是重复确认。快重传算法规定，发送方只要一连收到3个重复确认，就知道接收方确实没有收到报文段 M3 ，因而应当立即进行重传（即“快重传”)，这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。使用快重传可以使整个网络的吞吐量提高约20%，如下图所示
因此，在上图中的点④，发送方知道现在只是丢失了个别的报文段。于是不启动慢开始，而是执行快恢复算法。这时，发送方调整门限值 ssthresh = cwnd /2=8，同时设置拥塞窗口 cwnd = ssthresh =8（图中点⑤），并开始执行拥塞避免算法。
根据以上所述， TCP 的拥塞控制可以归纳为下面的流程图。这个流程图就比上图所示的特例要更加全面些。例如，上图没有说明在慢开始阶段如果出现了超时（即出现了网络拥塞）或出现3-ACK，发送方应采取什么措施。但从下图的流程图就可以很明确地知道发送方应采取的措施。

连接管理

TCP 是面向连接的协议。运输连接是用来传送 TCP 报文的。 TCP 运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接就有三个阶段，即连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。
在 TCP 连接建立过程中要解决以下三个问题：

1. 要使每一方能够确知对方的存在。
2. 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）。
3. 能够对运输实体资源（如缓存大小、连接表中的项日等）进行分配。
   TCP 连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户(client)，而被动等待连接建立的应用进程叫做服务器（ server )。

连接建立

TCP建立链接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段，下图为经典三次握手
（tips：上文提到当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。）

第一次握手：客户端将同步位 SYN =1，初始序号 seq = x 发送到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到连接请求报文段后，必须向客户发送确认，在确认报文段中应把 SYN 位和 ACK 位都置1，确认号是 ack = x +1，并选择自己的初始号seq = y，此时服务器进入SYN_RECV状态;
第三次握手：客户端收到服务器的确认后，向服务器发送确认报文段，ACK = 1，确认号ack = y + 1，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手
注意：

1. TCP 的标准规定， ACK 报文段可以携带数据，但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq = x +1
2. 先发送一个确认报文段（ ACK =1, ack = x +1)，然后再发送一个同步报文段（ SYN =1, seq = y )。这样的过程就变成了四报文握手，但效果是一样的。

为什么客户端最后一次也要发送确认呢？/可以两次握手吗？

1. 三次握手才可以阻止重复历史连接的初始化（主要原因）
   主要是因为在两次握手的情况下，服务端没有中间状态给客户端来阻止历史连接，导致服务端可能建立一个历史连接，造成资源浪费。两次握手的情况下，服务器在收到 SYN 报文后，就进入 ESTABLISHED 状态，意味着这时可以给对方发送数据，但是客户端此时还没有进入 ESTABLISHED 状态，假设这次是历史连接，客户端判断到此次连接为历史连接，那么就会回 RST 报文来断开连接，而服务器在第一次握手的时候就进入 ESTABLISHED 状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到 RST 报文后，才会断开连接，这中间就造成了资源浪费
   
   在三次握手的情况下， 在服务端建立连接之前可以阻止掉了历史连接，从而保证建立的连接不是历史连接。
   如果是历史连接（序列号过期或超时），则第三次握手发送的报文是 RST 报文，以此中止历史连接；
   如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接
2. 三次握手才可以同步双方的初始序列号

序列号是可靠传输的一个关键因素，它的作用：

• 接收方可以去除重复的数据；
• 接收方可以根据数据包的序列号按序接收；
• 可以标识发送出去的数据包中， 哪些是已经被对方收到的；

所以序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
3. 三次握手才可以避免资源浪费
如果只有「两次握手」，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

连接释放

下面为《计算机网络 第七版》谢希仁版 中四次挥手的讲解，也可以直接看图
数据传输结束后，通信的双方都可释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。 A 把连接释放报文段首部的终止控制位 FIN 置1，其序号 seq = u ，它等于前面己传送过的数据的最后一个字节的序号加1。这时 A 进入 FIN - WAIT -1（终止等待1）状态，等待 B 的确认。请注意， TCP 规定， FIN 报文段即使不携带数据，它也消耗掉一个序号。
B 收到连接释放报文段后即发出确认，确认号是 ack = u +1，而这个报文段自己的序号是 v ，等于 B 前面已传送过的数据的最后一个字节的序号加1。然后 B 就进入 CLOSE － WAIT （关闭等待）状态。 TCP 服务器进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（ half - close ）状态，即 A 已经没有数据要发送了，但 B 若发送数据， A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。
A 收到来自 B 的确认后，就进入 FIN - WAIT -2（终止等待2）状态，等待 B 发出的连接释放报文段。
若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN =1。现假定 B 的序号为 w （在半关闭状态 B 可能又发送了一些数据）。 B 还必须重复上次已发送过的确认号 ack = u +1。这时 B 就进入 LAST - ACK （最后确认）状态，等待 A 的确认。
A 在收到 B 的连接释放报文段后，必须对此发出确认。在确认报文段中把 ACK 置1，确认号 ack = w +1，而自己的序号是 seq = u +1（根据 TCP 标准，前面发送过的 FIN 报文段要消耗一个序号）。然后进入到 TIME - WAIT （时间等特）状态，请注意，现在 TCP 连接还没有释放掉。必须经过**时间等待计时器（ TIME - WAIT timer ）**设置的时间2MSL后， A 才进入到 CLOSED 状态。

这篇文章中用比较容易理解的话语总结：假设客户端发起中断连接请求，也就是发送FIN报文，这时客户端就进入FIN_WAIT_1（终止等待1）状态。服务端接到FIN报文后，意思是说"我客户端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，告诉客户端，“你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候客户端就进入FIN_WAIT_2（终止等待2）状态，继续等待服务端的FIN报文。当服务端确定数据已发送完成，则向客户端发送FIN报文，“告诉客户端，好了，我这边数据发完了，准备好关闭连接了”。客户端收到FIN报文后，就知道可以关闭连接了，但是他还是不相信网络，怕服务端不知道要关闭，所以发送ACK后进入TIME_WAIT（时间等待）状态，如果服务端没有收到ACK则可以重传。服务端收到ACK后，就知道可以断开连接了。客户端等待了2MSL后依然没有收到回复，则证明服务端已正常关闭，那好，我客户端也可以关闭连接了。OK，TCP连接就这样关闭了！

为什么连接的时候是三次握手，关闭的时候却是四次握手？

• 因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
• 但是关闭连接时，当服务端收到FIN报文时，通常需要等待完成数据的发送和处理，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

为什么 TIME_WAIT 等待的时间是 2MSL？
MSL 是报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。
MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。
TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是： 网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。比如如果服务端没有收到断开连接的最后的 ACK 报文，就会触发超时重发 FIN 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方， 一来一去正好 2 个 MSL。2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。

应用层

域名系统DNS

域名系统DNS是互联网使用的命名系统，用来把便于人们使用的机器名字转换为IP地址。域名系统其实就是名字系统。为什么不叫“名字”而叫“域名”呢？这是因为在这种互联网的命名系统中使用了许多的“域”,因此就出现了“域名”这个名词。“域名系统”很明确地指明这种系统是用在互联网中的。
从理论上讲，整个互联网可以只使用一个域名服务器，使它装入互联网上所有的主机名，并回答所有对IP地址的查询。然而这种做法并不可取。因为互联网规模很大，这样的域名服务器肯定会因过负荷而无法正常工作，而且–旦域名服务器出现故障，整个互联网就会瘫痪。因此，早在1983年互联网就开始采用层次树状结构的命名方法，并使用分布式的域名系统DNS。DNS的互联网标准是RFC 1034, 1035。
互联网的域名系统DNS被设计成为-一个联机分布式数据库系统，并采用客户服务器方式。DNS使大多数名字都在本地进行解析，仅少量解析需要在互联网上通信，因此DNS系统的效率很高。由于DNS是分布式系统，即使单个计算机出了故障，也不会妨碍整个DNS系统的正常运行
互联网采用层次树状结构的命名方法。采用这种命名方法，任何一个连接在互联网上的主机或路由器，都有一个唯一的层次结构的名字，即域名。这里，“域”是名字空间中一个可被管理的划分。域还可以划分为子域，而子域还可继续划分为子域的子域，这样就形成了顶级域、二级域、三级域，等等。从语法上讲，每一个域名都由标号序列组成，而各标号之间用点隔开(请注意，是小数点“”，不是中文的句号“。”)
例如：

原先的顶级域名共分为三大类：

1. 国家顶级域名nTLD。如：cn为中国
2. 通用顶级域名gTLD。如：com为公司企业；net为网络服务机构；org为非营利性组织；int为国际组织等
3. 基础结构域名：这种顶级域名只有一个，即arpa，用于反向域名解析
   我国把二级域名划分为”类别域名“和”行政区域名“两大类
   类别域名共七个，分别为ac（科研机构），com（工、商、金融等企业）、edu（中国的教育机构）、gov（中国的政府机构）、mil（中国的国防机构）、net（提供互联网络服务的机构）、org（非营利性的组织）
   行政区域名工34个，适用于各省、自治区、直辖市。例如：bj（北京市）
   域名树：
   
   
   应当注意，虽然中央电视台和清华大学都各有一台计算机取名为mail,但它们的域名并不一样，因为前者是mail.cctv.com，而后者是mail.tsinghua.edu.cn。 因此，即使在世界上还有很多单位的计算机取名为mail,但是它们在互联网中的域名都必须是唯一的。
   这里还要强调指出，互联网的名字空间是按照机构的组织来划分的，与物理的网络无关，与IP地址中的“子网”也没有关系。

文件传送协议FTP

概述

网络环境中的一项基本应用就是将文件从一台计算机中复制到另一台可能相距很远的计算机中。初看起来，在两台主机之间传送文件是很简单的事情。其实这往往非常困难。原因是众多的计算机厂商研制出的文件系统多达数百种，且差别很大。经常遇到的问题是:

1. 计算机存储数据的格式不同。
2. 文件的目录结构和文件命名的规定不同。
3. 对于相同的文件存取功能，操作系统使用的命令不同。
4. 访问控制方法不同。

文件传送协议 FTP 是因特网上使用得最广泛的文件传送协议，提供交互式的访问，允许客户指明文件的类型与格式，并允许文件具有存取权限。

FTP 特点

1. 文件传送协议 FTP 只提供文件传送的一些基本的服务，它使用 TCP 可靠的运输服务。
2. FTP 的主要功能是减少或消除在不同操作系统下处理文件的不兼容性。
3. FTP 使用客户服务器方式。一个 FTP 服务器进程可同时为多个客户进程提供服务。FTP 的服务器进程由两大部分组成：一个主进程，负责接受新的请求；另外有若干个从属进程，负责处理单个请求，主进程与从属进程的处理是并发地进行。

FTP传输模式

1. 文本模式：ASCII模式，以文本序列传输数据；
2. 二进制模式：Binary模式，以二进制序列传输数据；

FTP 使用的两个 TCP 连接

特点中说到FTP有两大部分，其中主进程的工作步骤如下:

1. 打开熟知端口(端口号为21)， 使客户进程能够连接上。
2. 等待客户进程发出连接请求。
3. 启动从属进程处理客户进程发来的请求。从属进程对客户进程的请求处理完毕后即终止，但从属进程在运行期间根据需要还可能创建其他一些子进程。
4. 回到等待状态，继续接受其他客户进程发来的请求。主进程与从属进程的处理是并发进行的。

FTP的工作情况如下图所示。图中的椭圆圈表示在系统中运行的进程。图中的服务器端有两个从属进程：控制进程和数据传送进程。为简单起见，服务器端的主进程没有画上。客户端除了控制进程和数据传送进程外，还有一个用户界面进程用来和用户接口。
在进行文件传输时，FTP的客户和服务器之间要建立两个并行的TCP连接：“控制连接”和“数据连接”。控制连接在整个会话期间一直保持打开，FTP客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。数据传送进程实际完成文件的传送，在传送完毕后关闭“数据传送连接”并结束运行。由于FTP使用了一个分离的控制连接，因此FTP的控制信息是带外传送的。

使用两个独立的连接的主要好处是使协议更加简单和更容易实现，同时在传输文件时还可以利用控制连接对文件的传输进行控制。例如，客户发送“请求终止传输”。
FTP并非对所有的数据传输都是最佳的。例如，计算机A上运行的应用程序要在远地计算机B的一个很大的文件末尾添加一行信息。若使用FTP，则应先将此文件从计算机B传送到计算机A，添加上这一行信息后，再用FTP将此文件传送到计算机B，来回传送这样大的文件很花时间。实际上这种传送是不必要的，因为计算机A并没有使用该文件的内容。
然而网络文件系统NFS则采用另一种思路。NFS允许应用进程打开一个远地文件，并能在该文件的某一个特定的位置上开始读写数据。这样，NFS可使用户只复制一个大文件中的一个很小的片段，而不需要复制整个大文件。对于上述例子，计算机A中的NFS客户软件，把要添加的数据和在文件后面写数据的请求一起发送到远地的计算机B中的NFS服务器，NFS服务器更新文件后返回应答信息。在网络上传送的只是少量的修改数据。

简单文件传送协议TFTP

虽然TFTP也使用客户服务器方式，但它使用UDP数据报，因此TFTP需要有自己的差错改正措施。TFTP只支持文件传输而不支持交互。TFTP没有一个庞大的命令集，没有列目录的功能，也不能对用户进行身份鉴别。
TFTP的主要优点有两个。
第一，TFTP可用于UDP环境。例如，当需要将程序或文件同时向许多机器下载时就往往需要使用TFTP。
第二，TFTP代码所占的内存较小。这对较小的计算机或某些特殊用途的设备是很重要的。这些设备不需要硬盘，只需要固化了TFTP、UDP和IP的小容量只读存储器即可。当接通电源后，设备执行只读存储器中的代码，在网络上广播一个TFTP请求。网络上的TFTP服务器就发送响应，其中包括可执行二进制程序。设备收到此文件后将其放入内存，然后开始运行程序。这种方式增加了灵活性，也减少了开销。
TFTP的主要特点是:

1. 每次传送的数据报文中有512字节的数据，但最后一次可不足512字节。
2. 数据报文按序编号，从1开始。
3. 支持ASCII码或二进制传送。
4. 可对文件进行读或写。
5. 使用很简单的首部。

TFTP的工作很像停止等待协议。发送完一个文件块后就等待对方的确认，确认时应指明所确认的块编号。发完数据后在规定时间内收不到确认就要重发数据PDU。发送确认PDU的一方若在规定时间内收不到下一个文件块，也要重发确认PDU。这样就可保证文件的传送不致因某–个数据报的丢失而告失败。

统一资源定位符URL

统一资源定位符URL是用来表示从互联网上得到的资源位置和访问这些资源的方法。URL相当于一个文件名在网络范围的扩展，是与互联网相连的机器上任何可访问对象的一个指针。由于访问不同对象所使用的协议不同，所以URL还指出读取某个对象时所使用的协议。URL的一般形式由以下四个部分组成：
<协议>://<主机>:<端口>/<路径>
URL的第一部分是最左边的<协议>。这里的<协议>就是指出使用什么协议来获取该万维网文档。现在最常用的协议就是http (超文本传送协议HTTP),其次是ftp (文件传送协议FTP)。
在<协议>后面的 :// 是规定的格式。它的右边是第二部分<主机>，它指出这个万维网文档是在哪一台主机上。这里的<主机>就是指该主机在互联网上的域名。再后面是第三和第四部分<端口>和<路径>，有时可省略。
现在有些浏览器为了方便用户，在输入URL时，可以把最前面的“http://"甚至把主机名最前面的“www”省略，然后浏览器替用户把省略的字符添上。例如，用户只要键入baidu.com,浏览器就自动把未键入的字符补齐，变成http://www.baidu.com.
用法举例：
动物住址协议://地球/中国/陕西省/西安市/长安区/西安邮电大学/1号宿舍楼/5号寝/张三.人

超文本传送协议HTTP

从层次角度看，HTTP是面向事务的应用层协议，是万维网上能够可靠地交换文件的重要基础。
HTTP使用了面向连接的TCP作为运输层协议，保证了数据的可靠传输。HTTP不必考虑数据在传输过程中被丢弃后又怎样被重传。但是，HTTP协议本身是无连接的。这就是说，虽然HTTP使用了TCP连接，但通信的双方在交换HTTP报文之前不需要先建立HTTP连接。在1997年以前使用的是RFC 1945 定义的HTTP/1.0协议。现在普遍使用的升级版本HTTP/1.1已是互联网建议标准[RFC 7231]。
HTTP协议是无状态的。也就是说，同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时的相同(假定现在服务器还没有把该页面更新)，因为服务器并不记得曾经访问过的这个客户，也不记得为该客户曾经服务过多少次。HTTP的无状态特性简化了服务器的设计，使服务器更容易支持大量并发的HTTP请求。

从上图可看出，请求一个万维网文档所需的时间是该文档的传输时间(与文档大小成正比)加上两倍往返时间RTT (一个RTT用于连接TCP连接，另一个RTT用于请求和接收万维网文档。TCP建立连接的三报文握手的第三个报文段中的数据，就是客户对万维网文档的请求报文)。
HTTP/1.0的主要缺点，就是每请求一个文档就要有两倍RTT的开销。若一个主页上有很多链接的对象(如图片等)需要依次进行链接，那么每一次链接下载都导致2×RTT的开销。另一种开销就是万维网客户和服务器每一次建立新的TCP连接都要分配缓存和变量。特别是万维网服务器往往要同时服务于大量客户的请求，所以这种非持续连接会使万维网服务器的负担很重。好在浏览器都能够打开5 ~ 10个并行的TCP连接，而每一个TCP连接处理客户的一个请求。因此，使用并行TCP连接可以缩短响应时间。
HTTP/1.1协议较好地解决了这个问题，它使用了持续连接。 所谓持续连接就是万维网服务器在发送响应后仍然在一段时间内保持这条连接，使同一个客户(浏览器)和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。这并不局限于传送同一个页面上链接的文档，而是只要这些文档都在同一个服务器上就行。
HTTP/1.1协议的持续连接有两种工作方式，即非流水线方式和流水线方式。
非流水线方式的特点，是客户在收到前一个响应后才能发出下一个请求。因此，在TCP连接已建立后，客户每访问一次对象都要用去一个往返时间RTT。这比非持续连接要用去两倍RTT的开销，节省了建立TCP连接所需的一个RTT时间。但非流水线方式还是有缺点的，因为服务器在发送完一个对象后，其TCP连接就处于空闲状态，浪费了服务器资源。
流水线方式的特点，是客户在收到HTTP的响应报文之前就能够接着发送新的请求报文。于是一个接一个的请求报文到达服务器后，服务器就可连续发回响应报文。因此，使用流水线方式时，客户访问所有的对象只需花费一个RTT时间。流水线工作方式使TCP连接中的空闲时间减少，提高了下载文档效率。

HTTP版本对比

• http1.0和http1.1的区别

1. 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2. 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3. 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
4. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

• http1.1和http2.0的区别

1. 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
2. 多路复用（MultiPlexing），即连接共享，即每一个request都是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
3. header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
4. 服务端推送（server push）

HTTP报文结构

HTTP报文分为两类报文：

1. 请求报文：从客户向服务器发送请求报文
   
2. 响应报文：从服务器到客户的回答
   
   HTTP请求报文的一些方法：
   

下面是HTTP的请求报文的开始行（即请求行）的格式，请注意，在GET后面有一个空格，接着是某个完整的URL，其后面又有一个空格，最后是HTTP/1.1
GET http://www.xyz.edu.cn/dir/index.htm HTTP/1.1
下面是一个完整的HTTP请求报文的例子:
GET /dir/ index.htm HTTP/1.1 {请求行使用了相对URL}
Host: WWW .XyZ . edu. cn {此行是首部行的开始。这行给出主机的域名}
Connection: close {告诉服务器发送完请求的文档后就可释放连接}
User-Agent: Mozilla/5.0 {表明用户代理是使用火狐浏览器Firefox}
Accept - Language: cn {表示用户希望优先得到中文版本的文档}
{请求报文的最后还有一个空行}

再看看HTTP响应报文的主要特点：
每一个请求报文发出后，都能收到一个响应报文。响应报文的第一行就是状态行
状态行包括三项内容，即HTTP的版本，状态码，以及解释状态码的简单短语，状态码都是三位数字，分为5大类
1xx表示通知信息，如请求收到了或正在进行处理。
2xx表示成功，如接受或知道了。
3xx表示重定向，如要完成请求还必须采取进一步的行动。
4xx表示客户的差错，如请求中有错误的语法或不能完成。
5xx表示服务器的差错，如服务器失效无法完成请求。
下面三种状态行在响应报文中是经常见到的。
HTTP/ 1.1202 Accepted {接受}
HTTP/ 1.1400 Bad Request {错误的请求}
HTTP/1.1 404 Not Found {找不到}

HTTPS

上文提到的HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
HTTPS：是以安全为目标的 HTTP 通道，是 HTTP 的安全版。HTTPS 的安全基础是 SSL。即把添加了加密及认证机制的 HTTP 称为 HTTPS

HTTPS安全通信演化过程

使用这篇文章举的例子来理解安全传输原理
明文传输
洞洞：“呼叫洞妖，呼叫洞妖！”
洞妖：“我是洞妖，我是洞妖，有啥事？”
洞洞：“有个关于老板的八卦新闻，你要不要听？”
洞妖：“快讲，快讲……”
于是洞洞和洞妖"宾主双方"就"愉快"地聊起了八卦新闻。
有人偷听——对称加密算法
洞洞：“洞妖，洞妖。我这里又有新的八卦新闻，你要不要听？”
洞妖：“不要了，上一次我们聊八卦的事情，都被其它人知道了。我们通信都是明文的，在网络上感觉就像裸奔。”
洞洞：“……，要不这样，我们弄个加密算法，用密钥把我们的通信内容加密一下，传输给你，你通过解密算法用密钥解密，这样就不怕别人监听了，就像这样。”

洞妖：“好是好，可是密钥你要怎么给我呢？总不能这样刺裸裸的通过网络明文传输密钥吧。”
洞洞：“这倒也是。要不这样，我下次过去找你，随身带过去给你。”
洞妖：“成。”
在洞妖得到密钥之后，他们又可以愉快地聊天了。
可以公开的密钥——非对称加密算法
洞妖：“呼叫洞洞，呼叫洞洞！”
洞洞：“啥事？”
洞妖：“请教你一个问题，如果我想和其它人在网络上聊天，有没有其它的加密算法，我总不能一个个的先跑到他们身边把密钥当面告诉他们后，再通过网络聊天吧，如果这些人是天南地北的呢？”
洞洞：“有办法。有一种非对称加密算法，它有两个密钥，一个是公钥，可以明文传输的。一个是私钥，由我保存，其它人都不知道。加密和解密算法不同。你通过公钥加密的信息只有我用私钥才能解开，就像这样。”

洞妖：“好方法，那根据这个算法，我生成一套公钥私钥对，你也生成一套不同的公钥私钥对。我们各自告诉对方公钥。我传信息给你的时候，用你给的公钥加密，你用你的私钥解密。同样的，你给我发信息的时候，用我给的公钥加密，我收到信息后用我的私钥解密。”
洞洞：“聪明。来来来，我再和你说一个老板的八卦吧……”
有点慢——非对称加密算法+对称加密算法
洞妖：“洞洞，洞洞！”
洞洞：“咋了？”
洞妖：“你有没有发现，用非对称加密算法进行通信，其加解密过程特别慢？”
洞洞：“是有点慢。因为非对称加密算法运算量大。那要不这样，我们第一次用非对称加密算法传递对称加密算法的密钥，后续通信就用对称加密算法。除了第一次用非对称加密算法加解密密钥的时候比较慢外，其它时间都不会慢了。而且也可以保证对称加密算法密钥的安全性。这样可以充分利用非对称加密算法和对称加密算法的各自特点。”
洞妖：“妥！”
你是谁——数字证书
洞妖：“洞洞，洞洞！”
洞洞：“啥事？”
洞妖：“洞洞，你咋证明你洞洞呢？”
洞洞：“我去，这不就是和要证明你爹是你爹一个道理嘛。”
洞妖：“哈哈哈，别误会。我想说的是，会不会在我们通信过程中，有个中间人，而我们收到的公钥都是他的，他获取我们的各自消息，然后中转。那他就可以看到我们所有的信息，就像这样(中间人攻击)”

洞洞：“我去，如果中间人是老板，那我们不是死翘翘了。看来还是在公钥传输上出问题。你看，要不这样，我们找个可靠的人做公证人，我们各自把公钥交给他。由他让颁布一个证书，证书包含公钥以及我们的身份信息，来证明我们各自的身份。”
洞妖：“可行，不过如果证书在传输过程中被人篡改，别人偷窥了呢？”
洞洞：“可以让公证人用数字摘要算法，把公钥和身份信息生成一个摘要。同时用非对称加密算法把对摘要进行加密，生成数字签名。然后把【公钥和身份信息+数字签名】合并，形成数字证书。就像这样”

洞妖：“嗯，那我在获得数字证书的时候，就可以用公钥进行解密生成摘要信息，再用数字摘要算法对公钥和身份信息生成摘要信息，两者比对，如果能匹配，就说明没有被篡改。”

备注：数字证书通常来说是由受信任的数字证书颁发机构CA，在验证服务器身份后颁发。
谁值得信任——证书内置
洞妖：“等等，好像还有问题。公证人公钥传输过程也会出现中间人攻击问题。”
洞洞：“我去，我们采用数字证书方式就是为了解决公钥传输的中间人攻击问题，现在公证人的公钥传输也出现中间人攻击问题，死循环了。看来，这个公证人公钥只能事先通过其它途径给你了。”
洞妖：“我们把公证人公钥预先加载在操作系统中即可。”
洞洞：“完美！当然，如果操作系统和浏览器的公钥也被篡改，那我们就没招了。所以不要轻易信任安装未知证书。”
备注：微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的证书发布机构，把这些证书发布机构的证书默认安装在操作系统中，并且设置为操作系统信任的数字证书。

HTTPS安全通信过程

HTTPS的信任基于预先安装在操作系统中的证书颁发机构（CA）。可实现防篡改和中间人攻击。它的简易安全通信过程如下：

HTTP和HTTPS区别

1. HTTPS协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。
2. HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL/TLS加密传输协议。
3. HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4. HTTP的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。

HTTPS的性质

1. 数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么
2. 数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收
3. 身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方

参考文献

《计算机网络 第七版》谢希仁版
关于三次握手和四次挥手，面试官想听到怎样的回答？
TCP协议中的三次握手和四次挥手(图解)
HTTP与HTTPS的区别，详细介绍
HTTPS安全通信过程
HTTP版本比较