tcp的5个可靠机制(TCP的5个可靠机制的作用)

补充：1、建立连接的时候三次握手，解除连接的时候四次挥手； 2、确认机制：超时重传，捎带确认，合并确认；3、CRC校验机制4、流量控制：滑动窗口机制 5、拥塞控制：慢开始，拥塞避免，快重传，快恢复
简单说包括三个核心： 1、连接和断开时三次握手2、确认机制（超时、捎带确认、合并确认等）3、CRC校验机制 详细的原理就不是几句话能说清了，欢迎追问。
1、确认机制 2、超时重传 3、顺序重组

TCP发送的报文段是交给IP层传送的，但IP层只能提供尽最大努力服务。也就是说，TCP下面的网络所提供的是不可靠的传输。因此，TCP必须采用适当的措施才能使得两个传输层之间的通信变得可靠。理想的传输条件有以下特点：在这样的情况下，不采取任何措施就能实现可靠传输。然而实际的网络都不具备上述的两个条件。但是我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告知发送方降低数据发送的速度——流量控制。这样本来不可靠的信道就能实现可靠的传输。可靠传输：即发送端发送的是什么，接收端接收到的就是什么。也就是在数据传输的过程中没有传输差错。数据传输过程中可能出现的问题：比特出差错、丢包。可靠传输的方法：停止-等待协议、滑动窗口协议。(1) 全双工通信的双方既是发送方也是接收方，但是为了讨论问题方便，仅考虑一方发送数据（发送方），一方接收数据（接收方）。(2) 数据传输的过程中既可能出现差错，又有可能出现丢包的现象。(3) 所有传输的数据单元称为分组。发送方每发送一分组就停止等待，只有等到了接收方发送来的确认后才可以发送下一个分组。(1)分组丢失或检测到分组出错发送方在传输过程中分组丢失，这时接收方没有接收到分组不会知道发送方发送了分组，就不会给发送方返回确认信息（分组出错，接收方会直接丢弃分组也不会返回确认信息），而发送方在等待接收方的确认信息以此来发送下一个分组。所以可靠传输协议这样规定：当发送方超过一段时间没有仍然没有收到的确认，就认为刚才的分组丢失了，因而重传前面的发送过的分组。这就是超时重传。超时重传要求在每次发送完一个分组时设置一个超时计时器，如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。(2)确认分组（ACK）丢失接收端接收了发送方传输的分组后，向发送方发送ACK，但是ACK在传输过程中丢失了，那么发送方就收不到确认信息，这时发送端超时计时器到期后就要重传分组，接收方仍会重复接收分组，并且丢弃重复的分组，并重传ACK。(3)ACK分组迟到下图的传输过程没有出现差错，接收方接收分组后向发送方发送ACK，但是确认信息迟到了，在超时计时器到期后发送方会重新发送分组，接收方仍然会重复接收分组，并且丢弃重复的分组，并重传ACK。当发送方收到ACK后会发送下一个分组，在后来发送方收到迟到的ACK时，发送方会收下并直接丢失。优缺点：停止等待协议优点是简单，但缺点是信道利用率太低。假定A发送分组需要的时间是TD。显然，TD等于分组的长度除以数据率。再假定分组正确到达B后，B处理分组的时间可以忽略不计，同时立即发回确认。假定B发送确认分组需要时间TA，如果A处理确认分组的时间也可以忽略不计，那么A在经过（TD+ RTT + TA）后就可以再发送下一个分组，这里的RTT是往返时间。信道利用率：发送方在一个发送周期内，有效地发送数据所需要的时间占整个发送周期的比率。因为仅仅是在时间TD内才用来传送有用数据（包括分组的首部），因此信道利用率U为：为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输。流水线传输就是发送方可以连续发送多个分组，不必每次发完一个分组就停下来等待对方的确认。这样信道上一直有数据在不断的传送，显然这样会提供信道利用率。在回退N步协议中，允许发送方发送多个分组而不需等待确认，但它也受限于流水线中未确认的分组数不能超过某个最大允许数N。发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。如上图所示，发送方收到了对第0分组的确认后，将发送窗口向前移动一个分组的位置。上图表示了GBN协议的序号范围示意图。其中序号被分割成了四个部分，各个部分的含义如图所示。(1)上层的调用。(2)收到一个ACK：GBN协议中，对序号为n的分组的确认是采用累积确认（cumulative acknowledgement）的方式。(3)超时事件：如果发生超时事件，发送方重传所有已发送但还未被确认过的分组。(1) 如果接收方正确收到n号分组，并且按序（即上次交付给上层的分组序号是n-1），则接收方位分组n发送一个ACK，并将该分组交付给上层。(2) 其他情况，接收方丢弃分组，并为最近按序接收到的分组重新发送ACK。即GBN协议中，接收方丢失所有失序的分组，接收方不缓存任何的失序分组，只需要维护一个下一个按序接收的分组序号：expectedseqnum。很显然，GBN协议对失序的分组选择直接丢失的行为优点是使得接收缓存简单，即接收方不缓存任何失序的分组，但是缺点也是非常明显的，由于一个分组出错可能需要重传原来已经正确传送的分组，这对资源无疑是一种浪费，其次这些重传的分组也许也会丢失或出错，从而导致更多的重传。最后，用一个例子总结下一GBN协议的工作流程(1) 发送端发送0、1、2、3号分组，此时发送窗口已满，不能在发送新的分组，在4个分组的传输的过程中，其中2号分组丢失。(2) 接收方返回对0号分组的确认，此时窗口向前滑动一个分组位置，并同时发送4号分组。此时，由于0号分组已被确认，计时器重新启动，开始为分组1开始计时....(3) 接收方在接收到发送方的0号分组后期望接下来收到1号分组，但是没有收到1号分组，但是却收到2号分组和3号分组，所以直接丢失，并向发送方返回ACK 0，同样对于之后收到的4号分组也是直接丢失并返回ACK 0，此时窗口已经满了，也无法发送新的分组。(4) 在计时器超时后，发送方重传所有已发送但是没有被确认的分组，即1号、2号、3号和4号分组，如果这次没有分组丢失，那么接收方会返回这4个分组的确认，发送方在收到确认后，将窗口向前移动4个分组位置。(1)GBN协议使用累积确认机制。(2)接收方只按顺序接收分组，不按序的分组直接丢失。(3)重传时需要重传全部已发送但是没有被确认的分组。(4)确认序列号最大的、按序到达的分组。选择重传协议是对GBN协议的缺点进行了改进，GNB超时重传会对那些已经正确传送的分组都重新传送，并且对失序到达的分组直接丢失。选择重选协议通过让发送方仅重传那些可能在接收方出错（即丢失或受损）的分组而避免了不必须要的重传。SR协议的改进措施：下图表示选择重选协议的发送窗口和接收窗口。发送窗口和同步窗口是不同步的。(1)上层的调用。(2)收到一个ACK。如下图所示，当收到2号分组的确认后，窗口向前滑动一直到最小序号的未确认的分组处，即5号分组处。(3)超时：定时器再次被用来发送丢失的分组。每个分组都有自己的逻辑定时器，因为超时发生后只能发送一个分组。(1) SR接收方将确认一个正确接收的分组（在窗口内）而不管其是否按序。失序的分组将被缓存直到所有丢失的分组（即序号更小的分组）都被收到为止，这是才可将一批分组按序交付给上层，然后向前移动滑动窗口。如果接收方收到一个在窗口左侧的分组（确切的来说，左边一个窗口大小范围的序号分组，即rev_base - N~rev_base - 1），在这种情况下，必须发送一个ACk，即使该分组是接收方以前已确认的分组。对于其他情况，则忽略分组即可。下面的图可以表示SR协议的工作过程，具体分析过程和GBN协议相似，这里就不细说了。(1)对窗口内的分组逐一确认，收一个确认一个。(2)只传出错的分组。(3)接收方有缓存机制，存放失序的分组。

提到TCP和UDP的区别，很容易想到的就是TCP的可靠性，那TCP是通过什么机制实现了可靠性的呢？解释这个之前先来区分TCP中的大写ACK和小写ack。看一张经典的TCP三次握手过程图： 这张图里似乎有个大写的ACK也有个小写的ack，这也是容易混淆的地方。大写的ACK是控制位，在TCP报文头中有8个标志比特，也就是TCP报文头中有8位大小的数据是标志位，看一下TCP报文格式更好理解：它们中的多个可以同时被设置成1：CWR（Congestion Window Reduce）：拥塞窗口减少标志，用来表明它接收到了设置ECE标志的TCP包。并且，发送方收到消息之后，通过减小发送窗口的大小来降低发送速率。ECE（ECN Echo）：用来在TCP三次握手时表明一个TCP端是具备ECN功能的。在数据传输过程中，它也用来表明接收到的TCP包的IP头部的ECN被设置为 11，即网络线路拥堵。URG（Urgent）：表示本报文段中发送的数据是否包含紧急数据。URG=1时表示有紧急数据。当URG=1时，后面的紧急指针字段才有效。ACK：表示前面的确认号字段是否有效。ACK=1时表示有效。只有当 ACK=1时，前面的确认号字段才有效。TCP规定，连接建立后，ACK必须为 1。PSH（Push）：告诉对方收到该报文段后是否立即把数据推送给上层。如果值为1，表示应当立即把数据提交给上层，而不是缓存起来。RST：表示是否重置连接。如果RST=1，说明TCP连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。SYN：在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1时，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才为1。FIN：标记数据是否发送完毕。如果 FIN=1，表示数据已经发送完成，可以释放连接。这是大写的ACK，而小写的ack是确认序列号，和它一对的是seq即顺序序列号，也就是上图TCP报文格式中的Sequence Number和Acknowledgment Number。前面说了这么多只是为了区分TCP中的大写ACK和小写ack，也没其他方法就用大小写区分吧，本文关注的重点就是TCP中的seq和ack机制，通过它们实现了TCP的可靠性传输，当然TCP通过很多方面去保证了可靠性传输，这里seq和ack机制是防止数据丢失丢包的机制。顺序号seq：用来标识从TCP源端向TCP目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。理解起来就是TCP用顺序号对每个字节进行计数。由上图TCP报文格式中可以看出序号是 32bit 的无符号数，序号到达 后又重新开始计数。当建立一个新的连接时，顺序号字段包含由这个主机选择的该连接的初始顺序号 ISN （ Initial Sequence Number ），也就是说seq并不一定是从0开始的，所以刚在画TCP三次握手的时候，写的seq=x，即使还没有数据传输，seq包含了ISN后就成了一个随机数，并不是0。确认号ack：理解起来就一句话，所期望收到的下一个顺序号seq。TCP为应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输，也就是说服务端和客户端都可能成为数据接收或者数据发送的一端。数据发送端在发送TCP报文时，计算在本次seq计数内，之前所有发送的报文中数据长度之和是多少，也就是计数记到哪里了，这就是seq。然后再计算之前所有收到的报文中收到的数据长度之和是多少，这就是ack。需要注意的是seq和ack是分开计数的。需要注意的是，SYN和FIN的TCP报文传输虽然没有数据，但是数据长度算1，ACK的传输，数据长度算0。数据接收端收到TCP报文后，将这次报文中的seq取出来，和自己最后一次发送的ack对比，如果一致，则代表数据没有丢失，理解起来就是这次的顺序号和上次自己期望的顺序号一致嘛。如果不一致就说明有丢包发生。其实就是TCP用0~对每个字节进行计数，用下图举个例子解释一下：三个过程：1.A在发送某个TCP报文前，发现此时自己这边的seq计数已经到了x，那这次的报文中seq=x，也就是在一次seq计数内，该端之前所有发送的报文中数据长度之和为x。然后这次又在这个报文中携带了长度为100bit的数据。2.B在收到这个报文后，拿到报文中的seq=x，又拿到了长度为100bit的数据，然后回包的时候ack=x+100。意思是告诉B你已经发了x+100位的数据了，下次发包的时候别忘了把seq改成x+100。3.A收到B回的数据包后，拿到报文中的ack=x+100，然后和自己这边的计数着的seq一比对，如果一样，说明A发的B都收到了没问题，如果不一样，假如A一看自己这边的seq已经等于y了，也就是自己计数着的已经发送y位的数据了，可是听B的意思它才收到x+100位数据，丢包了呗。然后就是重发什么的是TCP的另外一些机制。TCP就是通过seq和ack机制去确认传输过程中有没有丢包现象，前面说在一次计数范围内，seq并不一定是从0开始的，可以当我们用Wireshark抓包时，上面显示的seq确实从0开始的，这是因为Wireshark等抓包软件为了让seq和ack展示更直观，自动帮我们减去了初始顺序号 ISN，当然也可以设置为直接展示真正的seq和ack，那就看着比较乱了，贴一张Wireshark处理后的seq和ack变化过程图： 图中前三步即TCP的三次握手，之后是数据传输。可以结合该图去更好的理解本文。

TCP/IP中有两个具有代表性的传输层协议，它们分别是TCP和UDP。TCP提供可靠的通信传输，而UDP则常被用于让广播和细节调控交给应用的通信传输。 IP首部中有一个协议字段，用来标识网络层的上一层所采用的是哪一种传输层协议。根据这个字段的协议号，就可以识别IP传输的数据部分究竟是TCP的内容，还是UDP的内容。同样，传输层的TCP和UDP，为了识别自己所传输的数据部分究竟应该发给哪个应用，也设定了这样一个编号。TCP/IP的众多应用协议大多以客户端/服务端的形式运行。客户端类似于客户的意思，是请求的发起端。而服务端则表示提供服务的意思，是请求的处理端。另外，作为服务端的程序有必要提前启动，准备接收客户端的请求。否则即使有客户端的请求发过来，也无法做到响应的处理。这些服务端程序在UNIX系统中叫做守护进程。例如HTTP的服务端程序是httpd（HTTP守护进程），而ssh的服务端程序是sshd（SSH守护进程）。在UNIX中并不需要将这些守护进程逐个启动，而是启动一个可以代表它们接收客户端请求的inetd（互联网守护进程）服务程序即可。它是一种超级守护进程，该超级守护进程收到客户端请求以后会创建新的进程并转换为sshd等各个守护进程。确认一个请求究竟发给的是哪个服务端（守护进程），可以通过所收到数据包的目标端口号轻松识别。TCP：TCP是面向连接的、可靠的流协议。流就是指不间断的数据结构，你可以把它想象成排水管道中的水流。当应用程序采用TCP发送消息时，虽然可以保证发送的顺序，但还是犹如没有任何间隔的数据流发送给接收端。TCP为提供可靠性传输，实行"顺序控制"或"重发控制"机制。此外还具备"流控制（流量控制）"、"拥塞控制"、提高网络利用率等众多功能。UDP：UDP是不具有可靠性的数据报协议。细微的处理它会交给上层的应用去完成。在UDP的情况下，虽然可以确保发送消息的大小，却不能保证消息一定会到达。因此，应用有时会根据自己的需求进行重发处理。TCP与UDP的区分：TCP用于在传输层有必要实现可靠传输的情况。由于它是面向有连接并具备顺序控制、重发控制等机制的，所以它可以为应用提供可靠传输。UDP主要用于那些对于高速传输和实时性有较高要求的通信或广播通信。数据链路和IP中的地址，分别指的是MAC地址和IP地址。前者用来识别同一链路中不同的计算机，后者用来识别TCP/IP网络中互连的主机和路由器。在传输层中也有这种类似于地址的概念，那就是端口号。端口号用来识别同一台计算机中进行通信的不同应用程序。因此，它也被称为程序地址。TCP/IP或UDP/IP通信中通常采用5个信息来识别一个通信。它们是"源IP地址"、"目标IP地址"、"协议号"、"源端口号"、"目标端口号"。只要其中某一项不同，则被认为是其他通信。标准既定的端口号：这种方法也叫静态方法。它是指每个应用程序都有其指定的端口号。但并不是说可以随意使用任何一个端口号。每个端口号都有其对应的使用目的。时序分配法：服务器有必要确定监听端口号，但是接收服务的客户端没必要确定端口号。在这种方法下，客户端应用程序可以完全不用自己设置端口号，而全权交给操作系统进行分配。操作系统可以为每个应用程序分配互不冲突的端口号。根据这种动态分配端口号的机制，即使是同一客户端程序发起多个TCP连接，识别这些通信连接的5部分数字也不会全部相同。端口号由其使用的传输层协议决定。因此，不同的传输协议可以使用相同的端口号。数据到达IP层后，会先检查IP首部中的协议号，再传给相应协议的模块。如果是TCP则传给TCP模块，如果是UDP则传给UDP模块去做端口号的处理。即使是同一端口号，由于传输协议是各自独立地进行处理，因此相互之间不会受到影响。UDP不提供复杂的控制机制，利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立刻按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况，UDP也无法进行流量控制等避免网络拥塞的行为。此外，传输途中即使出现丢包，UDP也不负责重发。甚至当出现包的到达顺序乱掉时也没有纠正功能。如果需要这些细节控制，那么不得不交由采用UDP的应用程序去处理。由于UDP面向无连接，它可以随时发送数据。再加上UDP本身的处理既简单又高效，因此经常用于以下几个方面：TCP是对"传输、发送、通信"进行"控制"的"协议"。它充分地实现了数据传输时各种控制功能，可以进行丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。为了通过IP数据报实现可靠性传输，需要考虑很多事情。例如数据的破坏、丢包、重复以及分片顺序混乱等问题。TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。在TCP中，当发送端的数据到达接收主机时，接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答。序列号是按照顺序给发送数据的每一个字节都标上号码的编号。接收端查询接收数据TCP首部中的序列号和数据的长度，将自己下一步应该接受的序号作为应答返送回去。就这样，通过序列号和确认应答号，TCP可以实现可靠传输。重发超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。如果超过了这个时间仍未收到确认应答，发送端将进行数据重发。重发超时的计算既要考虑往返时间又要考虑偏差是有其原因的。根据网络环境的不同往返时间可能会产生大幅度的摇摆，之所以发生这种情况是因为数据包的分段是经过不同路线到达的。TCP/IP的目的是即使在这种环境下也要进行控制，尽量不要浪费网络流量。数据被重发之后若还是收不到确认应答，则进行再次发送。此时，等待确认应答的时间将会以2倍、4倍的指数函数延长。此外，数据也不会被无限、反复地重发。达到一定重发次数之后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接。并且通知应用通信异常强行终止。TCP提供面向有连接的通信传输。面向有连接是指在数据通信开始之前先做好通信两端之间的准备工作。在数据通信之前，通过TCP首部发送一个SYN包作为建立连接的请求等待确认应答。如果对端发来确认应答，则认为可以进行数据通信。如果对端的确认应答未能到达，就不会进行数据通信。此外，在通信结束时会进行断开连接的处理。可以使用TCP首部用于控制的字段来管理TCP连接。一个连接的建立与断开，正常过程至少需要来回发送7个包才能完成。在建立TCP连接的同时，也可以确定发送数据包的单位，我们也可以称其为"最大消息长度"（MSS）。最理想的情况是，最大消息长度正好是IP中不会被分片处理的最大数据长度。MSS是在三次握手的时候，在两端主机之间被计算得出。两端的主机在发出建立连接请求时，会在TCP首部中写入MSS选项，告诉对方自己的接口能够适应的MSS的大小。然后会在两者之间选择一个较小的投入使用。TCP以1个段为单位，每发一个段进行一次确认应答的处理。这样的传输方式有一个缺点。那就是，包的往返时间越长通信性能就越低。为了解决这个问题，TCP引入了窗口这个概念。即使在往返时间较长的情况下，它也能控制网络性能的下降。窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。在未使用窗口控制时，没有收到确认应答的数据都会被重发。而使用了窗口控制，某些确认应答即使丢失也无需重发。其次，我们来考虑一下某个报文段丢失的情况。接收主机如果收到一个自己应该接收的序号以外的数据时，会针对当前位置收到的数据返回确认应答。当某一报文段丢失后，发送端会一直收到序号为1001的确认应答，这个确认应答提醒发送端，"我想接收的是从1001开始的数据"。TCP提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量。这就是所谓的流控制。它的具体操作是，接收端主机向发送端主机通知自己可以接收数据的大小，于是发送端会发送不超过这个限度的数据。这大小限度被称作窗口大小。窗口大小的值就是由接收端主机决定的。当接收端从3001号开始的数据段后其缓冲区即满，不得不暂时停止接收数据。之后，在收到发送窗口更新通知后通信才得以继续进行。有了窗口控制，收发主机之间可以不再以一个数据段为单位发送确认应答，也能够连续发送大量数据包。但是如果在通信刚开始时就发送大量数据，也有可能会引发其他问题。TCP为了防止该问题的出现，在通信一开始时就会通过一个叫做慢启动的算法得出的数值，对发送数据量进行控制。首先，为了在发送端调节所要发送数据的量，定义了一个叫做"拥堵窗口"的概念。于是在慢启动的时候，将这个拥堵窗口的大小设置为1个数据段（1 MSS）发送数据，之后每收到一次确认应答（ACK），拥堵窗口的值就加1。在发送数据包时，将拥堵窗口的大小与接收端主机通知的窗口大小做比较，然后按照它们当中较小那个值，发送比其还要小的数据量。如果重发采用超时机制，那么拥塞窗口的初始值可以设置为1以后再进行慢启动修正。有了上述这些机制，就可以有限的减少通信开始时连续发包导致的网络拥堵，还可以避免网络拥塞情况的发生。不过，随着包的每次往返，拥塞窗口也会以1、2、4等指数函数的增长，拥堵状况激增甚至导致网络拥塞的发生。为了防止这些，引入了慢启动阀值的概念。只要拥塞窗口的值超出这个阀值，在每收到一次确认应答时，只允许以下面这种比例放大拥塞窗口:TCP的通信开始时，并没有设置相应的慢启动阈值。而是在超时重传时，才会设置为当前拥塞窗口一半的大小。由于重复确认应答而触发的高速重发与超时重发机制的处理多少有些不同。因为前者要求至少3次的确认应答数据段到达对方主机后才触发，相比后者网络的拥堵要轻一些。而由重复确认应答进行高速重发控制时，慢启动阈值的大小被设置为当时窗口大小的一半，然后将窗口的大小设置为该慢启动阈值+3个数据段的大小。当TCP通信开始以后，网络吞吐量会逐渐上升，但是随着网络拥堵的发生吞吐量也会急剧下降。于是会再次进入吞吐量慢慢上升的过程。因此所谓TCP的吞吐量的特点就好像是在逐步占领网络带宽的感觉。UDP-Lite（Lightweight User Datagram Protocol，轻量级用户数据报协议）是扩展UDP机能的一种传输层协议。在基于UDP的通信当中如果校验和出现错误，所收到的包将被全部丢弃。然而，现实操作中，有些应用在面对这种情况时并不希望把已经收到的所有包丢弃。如果将UDP中校验和设置为无效，那么即使数据的一部分发生错误也不会将整个包废弃。不过，这不是一个很好的方法。因为如果发生的错误有可能是UDP首部中的端口号被破坏或是IP首部中的IP地址被破坏，就会产生严重后果。因此，不建议将校验和关闭。为了解决这些问题，UDP的修正版UDP-Lite协议就出现了。UDP-Lite提供与UDP几乎相同的功能，不过计算校验和的范围可以由应用自行决定。这个范围可以是包加上伪首部的校验和计算，可以是首部与伪首部的校验和计算，也可以是首部、伪首部与数据从起始到中间某个位置的校验和计算。有了这样的机制，就可以只针对不允许发生错误的部分进行校验和的检查。 对于其他部分，即使发生了错误，也会被忽略不计。而这个包也不会被丢弃，而是直接传给应用继续处理。SCTP（Stream Control Transmission Protocol，流控制传输协议）与TCP一样，都是对一种提供数据到达与否相关可靠性检查的传输层协议。其主要特点如下：SCTP主要用于进行通信的应用之间发送众多较小消息的情况。这些较小的应用消息被称作数据块（Chunk），多个数据块组成一个数据包。此外，SCTP具有支持多重宿主以及设定多个IP地址的特点。多重宿主是指同一台主机具备多种网络的接口。例如，笔记本电脑既可以连接以太网又可以连接无线LAN。同时使用以太网和无线LAN时，各自的NIC会获取到不同的IP地址。进行TCP通信，如果开始时使用的是以太网，而后又切换为无线LAN,那么连接将会被断开。因为从SYN到FIN包必须使用同一个IP地址。然而在SCTP的情况下，由于可以管理多个IP地址使其同时进行通信，因此即使出现通信过程当中以太网与无线LAN之间的切换，也能够保持通信不中断。所以SCTP可以为具备多个NIC的主机提供更可靠的传输。DCCP（Datagram Congestion Control Protocol，数据报拥塞控制协议）是一个辅助UDP的崭新的传输层协议。UDP没有拥塞控制机制。为此，当应用使用UDP发送大量数据包时极容易出现问题。互联网中的通信，即使使用UDP也应该控制拥塞。而这个机制开发人员很难将其融合至协议中，于是便出现了DCCP这样的规范。DCCP具有如下几个特点： TCP首部比UDP首部要复杂得多。TCP中没有表示包长度和数据长度的字段。可由IP层获知TCP的包长，由TCP的包长可知数据的长度。

总结一下，TCP通过下列方式来提供可靠性：1）面向字节流和缓存机制：应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据长度将保持不变。由TCP传递给IP的信息单位称为报文段或段（segment）。2）超时重发和确认机制：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当TCP收到发自TCP连接另一端的数据，它将发送一个确认。TCP有延迟确认的功能，在此功能没有打开，则是立即确认。功能打开，则由定时器触发确认时间点。3）检验和机制：TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。4）字节编号机制：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。5）自动丢弃重复机制：既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。6）流量控制：TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。两个应用程序通过TCP连接交换8bit字节构成的字节流。TCP不在字节流中插入记录标识符。我们将这称为字节流服务（byte stream service）。如果一方的应用程序先传10字节，又传20字节，再传50字节，连接的另一方将无法了解发方每次发送了多少字节。只要自己的接收缓存没有塞满，TCP 接收方将有多少就收多少。一端将字节流放到TCP连接上，同样的字节流将出现在TCP连接的另一端。另外，TCP对字节流的内容不作任何解释。TCP不知道传输的数据字节流是二进制数据，还是ASCⅡ字符、EBCDIC字符或者其他类型数据。对字节流的解释由TCP连接双方的应用层解释。