前言

因特网为应用层提供了两种截然不同的可用运输层协议，一个是UDP（用户数据报协议），一个是TCP（传输控制协议），这两种协议无论是在开发过程中，还是面试问答中，都相当重要！！！
先了解两个定义：
多路分解：将运输层报文段中的数据交付到正确的套接字。
多路复用：在源主机从不同的套接字中收集数据块，并位每个数据块加上首部信息（将在以后进行分解）从而生成报文段，并将报文段传递到网络层。

一、UDP

1.定义

UDP不提供复杂的控制机制，利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立刻按照原样发送到网络上的一种机制。做了运输协议能够做的最少工作，除了复用/分解及极少的差错检测之外，几乎没有对ip增加别的东西。

2.特点

（1) UDP是无连接的，即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。

udp与tcp。(2) UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。

(3) UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文。

(4) UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。很多的实时应用（如IP电话、实时视频会议等）要去源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太多的时延。UDP正好符合这种要求。

(5) UDP支持一对一、一对多、多对一和多对多的交互通信。

(6) UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。

3.UDP的应用

如果开发人员选择UDP而不是TCP，则应用程序差不多就是直接和ip打交道。

为什么开发人员宁愿在udp之上建立应用，而不是首选tcp？（重点）

●关于发送什么教据以及何时发送的应用层控制更为精细。 采用UDP时，只要应用
进程将数据传递给UDP. UDP就会将此数据打包进UDP报文段井立即将其传递给
网络层。在另一方面，TCP有一 个拥塞控制机制，以便当源和目的主机间的- 条
或多条链路变得极度拥塞时来遏制运输层TCP发送方。TCP 仍将继续重新发送数
据报文段直到目的主机收到此报文并加以确认，而不管可靠交付需要用多长时间。
因为实时应用通常要求最小的发送速率，不希望过分地延迟报文段的传送，且能
容忍一些数据丢失，TCP服务模型并不是特别适合这些应用的需要。如后面所讨
论的，这些应用可以使用UDP，并作为应用的一部分来实现所需的、 超出UDP的
不提供不必要的报文段交付服务之外的额外功能。

●无须连接建立。如我们后面所讨论的，TCP在开始数据传输之前要经过三次握手。
UDP却不需要任何准备即可进行数据传输。因此UDP不会引人建立连接的时延。
这可能是DNS运行在UDP之上而不是运行在TCP之上的主要原因(如果运行在
TCP上，则DNS会慢得多)。HTTP使用TCP而不是UDP,因为对于具有文本数据
的Web网页来说，可靠性是至关重要的。但是，如我们在2.2节中简要讨论的那
样，HTTP中的TCP连接建立时延对于与下载Web文档相关的时延来说是一个重
要因素。用于谷歌的Chrome浏览器中的QUIC协议(快速UDP因特网连接[lyen-
gar 2015])将UDP作为其支撑运输协议并在UDP之上的应用层协议中实现可
靠性。

●无连接状态。TCP需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、
拥塞控制参数以及序号与确认号的参数。要实现TCP的可靠数据传输服务并提供拥塞控制，这些状态信息是必要的。另方面，UDP不维护连接状态，也不跟踪这些参数。因此，某些专门用于某种特定应用的服务器当应用程序运行在UDP之上而不是运行在TCP上时，一般都能 支持更多的活跃客户。

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

UDP的应用场景？
率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

3、报文段结构

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

一个UDP模块必须提供产生和验证检验和的功能，但是一个应用程序在使用UDP服务时，可以自由选择是否要求产生校检和。在计算校检和时，要在UDP用户数据报之前增加12字节的伪首部。校检和就是按照这个临时的UDP用户数据报来计算的。
UDP计算校检和的方法和计算IP数据报首部校检和的方法相似。但不同的是：IP数据报的校检和只校检IP数据报的首部，但UDP的校检和使把首部和数据部分一起都校检。

5、检验和

UDP检验和提供了差错检测功能，用于确定当UDP报文段从源到达目的地移动时，其中的比特是否发生改变。
虽然udp提供差错检测，但它对检错无能为力。udp的某种实现只是丢弃了受损的报文段，或者将受损的报文段交给应用程序并作出警告。

为什么udp首先提供检验和？
其原因是不能保证源和目的之间的所有链路都提供差错检测；这就是说，也许这些链路上的一条可能使用没有差错检测的协议，此外，即使经链路正确传输，当报文段存储在某台路由器上的内存中时，也可能出现比特差错。在既无法确保链路的可靠性，又无法确保内存比特差错，如果端到端数据传输要提供差错检测，udp就必须在端到端的基础上在运输层提供差错检测。

二、TCP

1.概述

TCP面向连接 ，是一种逻辑连接，其共同状态仅保留在两个通信端系统的tcp程序中，中间路由器对tcp完全视而不见，他们看到的是数据报而不是连接。

tcp连接是 全双工服务，两个进程存在连接，应用层数据可相互流向。

tcp连接也是点对点的。及单个发送方，单个接收方。

tcp的连接组成：一台主机上的缓存，变量，与进程连接的套接字，以及另一台主机的另一组缓存，变量，与进程连接的套接字，在这两台主机之间的网络因素（路由器，交换机，中继器）中，没有为该连接提供任何缓存和变量。

2.特点

面向连接（下面会详解）

字节流：TCP的字节流服务的表现形式就体现在，发送端执行的写操作数和接收端执行的读操作次数之间没有任何数量关系，当发送端应用程序连续执行多次写操作的时，TCP模块先将这些数据放入TCP发送缓冲区中。当TCP模块真正开始发送数据的时候，发送缓冲区中这些等待发送的数据可能被封装成一个或多个TCP报文段发出

可靠传输（下面会详解）

3.报文段结构

1、端口号：用来标识同一台计算机的不同的应用进程。

1）源端口：源端口和IP地址的作用是标识报文的返回地址。

2）目的端口：端口指明接收方计算机上的应用程序接口。

TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。

2、序号和确认号：是TCP可靠传输的关键部分。序号是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节一个序号。e.g.一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。确认号，即ACK，指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。

3、数据偏移／首部长度：4bits。由于首部可能含有可选项内容，因此TCP报头的长度是不确定的，报头不包含任何任选字段则长度为20字节，4位首部长度字段所能表示的最大值为1111，转化为10进制为15，15*32/8 = 60，故报头最大长度为60字节。首部长度也叫数据偏移，是因为首部长度实际上指示了数据区在报文段中的起始偏移值。

4、保留：为将来定义新的用途保留，现在一般置0。

5、控制位：URG ACK PSH RST SYN FIN，共6个，每一个标志位表示一个控制功能。

1）URG：紧急指针标志，为1时表示紧急指针有效，为0则忽略紧急指针。

2）ACK：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段。

3）PSH：push标志，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队。

4）RST：重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。

5）SYN：同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。

6）FIN：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流。

6、窗口：滑动窗口大小，用来告知发送端接受端的缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。窗口大小时一个16bit字段，因而窗口大小最大为65535。

7、校验和：奇偶校验，此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。由发送端计算和存储，并由接收端进行验证。

8、紧急指针：只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。

9、选项和填充：最常见的可选字段是最长报文大小，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项，它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍。

10、数据部分： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

1）序号和确定位

tcp报文段首部两个最重要的是序号和确认号字段，这两个字段是tcp可靠传输服务的关键部分。
tcp把数据看作一个无结构的、有序的字节流。
序号建立在传送的字节流之上，一个报文段的序号就是该报文段首字节的字节流编号。
确认号：主机A填充到进报文段的确认号，就是主机A期望从主机B收到的下一个字节的序号。
tcp只确认该流中至第一个丢失字节为止的字节，所以tcp被称为提供累计确认。
当主机在一条tcp连接中收到失序报文段时该怎么办？
1）接收方立即丢弃失序报文段（这样可以简化接收方的设记）
2）接收方保留失序的字节，并等待缺少的字节以填补该间隔。（实际应用）

4、往返时间的估计和超时

TCP采用超时重传的机制来处理报文段的丢失问题。
往返时间RTT：一个报文段发出到它被确认的时间。

(1)估计往返时间

方法如下：
报文段的样本RTT（Sample RTT）就是从某报文段被发出（即交给ip）到对该报文段的确认被收到的时间量。在任何时刻，仅为一个已经发送但未确认的报文段测量一个SampleRTT，从而产生一个接近每个RTT的样本RTT，不会为以重传的报文段计算SampleRTT（重传时间是先前值得两倍)。
由于路由器的拥塞和端系统的负载的变化，tcp也会位于一个SampleRTT的均值EstimateRTT

（2）设计和管理重传超时间隔

超时间隔应该大于等于EstimateRTT，否则会造成不必要的重传，也不必要大太多，否则报文丢失时不能很开快重传。

5、可靠的数据传输（重点）

TCP在IP不可靠的尽力而为得基础上创建了一种可靠的数据传输服务，确保一个进程从接收缓冲种读取数据流是无损伤，无间隙，非冗余和按序的数据流；
假设从A到B发送一个大文件
tcp发送方高度简化的描述：

（1）超时间间隔

TCP重传具有最小序号还未确认的报文段，只是每次重传都会将下一次的超时间隔设为先前值得两倍，成指数增长，然而当定时器在另外两个事件中的任意一个启动时（收到上层的数据或收到ACK），间隔时间由均值RTT与DevRTT计算得出。
这种方式优雅的解决了一定的网络拥塞。（后面会提）

（2）快速重传

超时触犯重传有一个问题就是超时时间可能过长，造成端与端的时延。解决方案就是，发送方在超时时间之前通过冗余ACK来检测丢包情况.
冗余ACK：发送已经收到该报文段的确认，再次受到ACK。
TCP的生成策略：

一旦收到三个冗余的ACK，TCP就会执行快速重传。

（3）选择确认

它允许TCP接收方有选择的确认失序报文段，而不是累计确认最后一个正确接受的有序报文段。

6.流量控制

TCP提供了流量控制服务，以消除发送方使接收方缓冲溢出的可能性。流量控制是一个速度匹配服务，及发送方的发送效率和接收方的接收效率相匹配。
TCP通过让发送方维护一个成为接收窗口（rwnd）的变量来提供流量控制，就是给发送方一个提示，该接收方还有多少可用的缓存空间。
rnwd使动态的 就是接收缓存（revbuffer）减去缓存中正在处理的数据。
连接中如何使用rwnd提供流量服务？
主机B通过把当前的rnwd值放入它发送它给主机A的报文段接收窗口字段中，通知主机A它在连接的缓冲还有多少空间

当主机B的接收窗口为0时，主机A继续发送只有一个字节数据的报文段。这些报文段将会被接收端确认。最终缓存将被开始清空，并且确定报文里将有一个非0的rwnd值。

7.TCP连接管理

（1）三次握手

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；服务器会从数据报中提取syn报文段，为该报文段分配tcp缓存和变量。

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。此时SYN被置为0，客户为该连接分配缓存和变量，并且第三次握手，可以在报文段中携带客户到服务器的数据。

1)SYN洪泛攻击

攻击者发送大量的tcp SYN报文段，而不完成第三步握手的过程，服务器为不断为这些半开连接分配资源。，导致服务器的连接资源被消耗殆尽。
解决方案：SYN cookie
工作方式：
●当服务器接收到一个SYN报文段时，它并不知道该报文段是来自一个合法的用户，还是一个SYN洪泛攻击开连接。相反， 服务器生成一个初始TCP序列号，该序列号是SYN报文段的源和目的IP地址与端口号以及仅有该服务器知道的秘密教的一个复杂函教(教列函教)。这种精心制作的初始序列号被称为“cokie" 服务器则发送具有这种特殊初始序列号的SYNACK分组。重要的是，服务器并不记忆该ce或任何对应于SYN的其他状态信息。
●如果客户是合法的，则它将返回一个ACK报文段。当服务器收到该ACK,需要验证该ACK是与前面发送的某些SYN相对应的。如果服务器没有维护有关SYN报文段的记忆，这是怎样完成的呢?正如你可能猜测的那样，它是借助于cookie来做到的。前面讲过对于一个合法的ACK，在确认字段中的值等于在SYNACK字段(此时为cookie值)中的值加1 (参见图3-39)。服务器则将使用在SYNACK报文段中的源和目的地IP地址与端口号(它们与初始的SYN中的相同)以及秘密数运行相同的散列函数。如果该函数的结果加1与在客户的SYNACK中的确认(cookie)值相同的话，服务器认为该ACK对应于较早的SYN报文段，因此它是合法的。服务器则生成一个具有套接字的全开的连接。
●在另一方面，如果客户没有返回一个ACK报文段，则初始的SYN并没有对服务器产生危害，因为服务器没有为它分配任何资源。

2）为什么不是两次握手？

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

（2）四次挥手

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

8.拥塞控制

在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏——产生拥塞(congestion)。出现资源拥塞的条件：对资源需求的总和 > 可用资源；拥塞带来的问题：若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。

（1）拥塞的控制方法一（慢开始和拥塞避免）

发送方维持一个叫做拥塞窗口 cwnd (congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如再考虑到接收方的接收能力，则发送窗口还可能小于拥塞窗口。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
　　慢开始算法原理：在主机刚刚开始发送报文段时可先设置拥塞窗口 cwnd = 1，即设置为一个最大报文段 MSS 的数值。在每收到一个对新的报文段的确认后，将拥塞窗口加 1，即增加一个 MSS 的数值。用这样的方法逐步增大发送端的拥塞窗口 cwnd，可以使分组注入到网络的速率更加合理。
　　传输轮次：使用慢开始算法后，每经过一个传输轮次，拥塞窗口 cwnd 就加倍。一个传输轮次所经历的时间其实就是往返时间 RTT。“传输轮次”更加强调：把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。例如，拥塞窗口 cwnd = 4，这时的往返时间 RTT 就是发送方连续发送 4 个报文段，并收到这 4 个报文段的确认，总共经历的时间。
慢开始门限 ssthresh 的用法如下：
当 cwnd < ssthresh 时，使用慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。
　　拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长。
　　
　　依据：超时，即没有按时收到确认。无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就要把慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口 cwnd 重新设置为 1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
　　“乘法减小“是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5。当网络频繁出现拥塞时，ssthresh 值就下降得很快，大大减少注入到网络中的分组数。
　　“加法增大”是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就把拥塞窗口 cwnd增加一个 MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。

（2） 拥塞的控制方法二（快重传与快恢复）

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接收方。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段。不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。

补充

1.可靠传输机制及其用途总结

2.tcp和udp的区别：

面向连接VS无连接
TCP建立一个连接需要3次握手IP数据包，断开连接需要4次握手。另外断开连接时发起方可能进入TIME_WAIT状态长达数分钟（视系统设置，windows一般为120秒），在此状态下连接（端口）无法被释放。
UDP不需要建立连接，可以直接发起。
可靠VS不可靠
TCP利用握手、ACK和重传机制，udp没有。
1，校验和（校验数据是否损坏）；
2，定时器（分组丢失则重传）；
3，序列号（用于检测丢失的分组和重复的分组）；
4，确认应答ACK（接收方告知发送方正确接收分组以及期望的下一个分组）；
5，否定确认（接收方通知发送方未被正确接收的分组）；
6，窗口和流水线（用于增加信道的吞吐量）。（窗口大小：无需等待确认应答而可以继续发送数据的最大值）
有序性
TCP利用seq序列号对包进行排序，udp没有。
面向字节流vs面向报文
面向报文
面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这也就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。（一个upd的最大报文长度2^16-1-20-8,20是ip报文头，8是udp报文头）
面向字节流
面向字节流的话，虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

tcp有流量控制，udp没有

tcp的头部比20bytes，udp8byres

3流行的因特网应用及其下面的运输协议