tcp和udp协议的网络(tcp 和udp协议的相似之处)

计算机网络七层模型中，传输层有两个重要的协议：（1）用户数据报协议UDP (User Datagram Protocol)（2）传输控制协议TCP (Transmission Control Protocol)UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP 报文后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下UDP 却是一种最有效的工作方式。TCP 则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。UDP 的主要特点是：首部手段很简单，只有8 个字节，由四个字段组成，每个字段的长度都是两个字节。前面已经讲过，每条TCP 连接有两个端点，TCP 连接的端点叫做套接字（socket）或插口。套接字格式如下：套接宁socket= (IP 地址：端口号’）每一条TCP 连接唯一地被通信两端的两个端点（即两个套接宇）所确定。即：TCP 连接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}3次握手链接4次握手释放链接断开连接请求可以由客户端发出，也可以由服务器端发出，在这里我们称A端向B端请求断开连接。各个状态节点解释如下：下面为了讨论问题的万便，我们仅考虑A发送数据而B 接收数据并发送确认。因此A 叫做发送方，而B 叫做接收方。“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest）。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。滑动窗口协议比较复杂，是TCP 协议的精髓所在。这里先给出连续ARQ 协议最基本的概念，但不涉提到许多细节问题。详细的滑动窗口协议将在后面讨论。下图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。连续ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都己正确收到了。累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。例如，如果发送方发送了前5 个分组，而中间的第3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N （回退N ），表示需要再退回来重传己发送过的N 个分组。可见当通信线路质量不好时，连续ARQ 协议会带来负面的影响。TCP 的滑动窗口是以字节为单位的。现假定A 收到了B 发来的确认报文段，其中窗口是20 （字节），而确认号是31 （这表明B 期望收到的下一个序号是31 ，而序号30 为止的数据己经收到了）。根据这两个数据， A 就构造出自己的发送窗口，其位置如图所示。发送窗口表示：在没有收到B 的确认的情况下， A可以连续把窗口内的数据都发送出去。凡是己经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。现在假定A 发送了序号为31 ～ 41 的数据。这时发送窗口位置并未改变，但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9 个字节（ 42 ～ 50 ）是允许发送但尚未发送的。】再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 号为止的数据是已经发送过确认，并且己经交付给主机了。因此在B 可以不再保留这些数据。接收窗口内的序号（31～50）足允许接收的。B 收到了序号为32 和33 的数据，这些数据没有按序到达，因为序号为31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。请注意， B 只能对按序收到的数据中的最高序号给出确认，因此B 发送的确认报文段中的确认号仍然是31 （即期望收到的序号）。现在假定B 收到了序号为31 的数据，并把序号为31～33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A 发送确认，其中窗口值仍为20，但确认号是34，这表明B 已经收到了到序号33 为止的数据。我们注意到，B还收到了序号为37, 38 和40 的数据，但这些都没有按序到达，只能先存在接收窗口。A收到B的确认后，就可以把发送窗口向前滑动3个序号，指针P2 不动。可以看出，现在A 的可用窗口增大了，可发送的序号范围是42～53。整个过程如下图：A 在继续发送完序号42-53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A 的发送窗口己满，可用窗口己减小到0，因此必须停止发送。上面已经讲到， TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP 最复杂的问题之一。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，TCP 保留了RTT的一个加权平均往返时间RTTs （这又称为平滑的往返时间， S 表示Smoothed 。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到RTT样本时， RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs:新的RTTs = (1 － α）×（旧的RTTs) ＋ α ×（新的RTT样本）α 越大表示新的RTTs受新的RTT样本的影响越大。推荐的α 值为0.125，用这种方法得出的加权平均往返时间RTTs 就比测量出的RTT值更加平滑。显然，超时计时器设置的超时重传时间RTO (RetransmissionTime-Out）应略大于上面得出的加权平均往返时间RTTs。RFC 2988 建议使用下式计算RTO:RTO = RTTs + 4 × RTTdRTTd是RTT 的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。计算公式如下：新的RTTd= (1- β）×（旧的RTTd) + β × |RTTs－新的RTT样本|发现问题：如图所示，发送出一个报文段。设定的重传时间到了，还没有收到确认。于是重传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的RTTs 和超时重传时间RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间RTO 就越来越长。若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTTs 和RTO 都会偏小。这就必然导致报文段过多地重传。这样就有可能使RTO 越来越短。Kam 提出了一个算法：在计算加权平均RTTs 时，只要报文段重传了就不采用其往返时间样本。这样得出的加权平均RTTs 和RTO 就较准确。新问题：设想出现这样的情况：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Kam 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。解决方案：对Kam 算法进行修正，方法是z报文段每重传一次，就把超时重传时间RTO 增大一些。典型的做法是取新的重传时间为2 倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的公式计算超时重传时间。流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。利用滑动窗口机制可以很方便地在TCP 连接上实现对发送方的流量控制。接收方的主机B 进行了三次流量控制。第一次把窗口减小到rwnd =300，第二次又减到rwnd = 100 ，最后减到rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B 重新发出一个新的窗口值为止。我们还应注意到，B 向A 发送的三个报文段都设置了ACK=1，只有在ACK=1 时确认号字段才有意义。发生死锁：现在我们考虑一种情况。上图中， B 向A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是B 向A 发送了rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A 一直等待收到B 发送的非零窗口的通知，而B 也一直等待A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。解决方案：TCP 为每一个连接设有一个持续计时器（persistence timer）。只要TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1 宇节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。1 TCP连接时是三次握手，那么两次握手可行吗？在《计算机网络》中是这样解释的：已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。2 为什么TCP连接是三次，挥手确是四次？在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后，B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。3 为什么在第四次挥手后会有2个MSL的延时？MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。假定网络不可靠，那么第四次发送的ACK可能丢失，即B端无法收到这个ACK，如果B端收不到这个确认ACK，B端会定时向A端重复发送FIN，直到B端收到A的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的。1 文件传送协议文件传送协议FTP (File Transfer Protocol) [RFC 959］是因特网上使用得最广泛的文件传送协议，底层采用TCP协议。盯P 使用客户服务器方式。一个FTP 服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求：另外有若干个从属进程，负责处理单个请求。在进行文件传输时，客户和服务器之间要建立两个并行的TCP 连接：“控制连接”（21端口）和“数据连接”（22端口）。控制连接在整个会话期间一直保持打开， FTP 客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP 客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。2 简单文件传送协议TFTPTCP/IP 协议族中还有一个简单文件传送协议TFfP (Trivial File Transfer Protocol），它是一个很小且易于实现的文件传送协议，端口号69。TFfP 也使用客户服务器方式，但它使用UDP 数据报，因此TFfP 需要有自己的差错改正措施。TFfP 只支持文件传输而不支持交耳。3 TELNETTELNET 是一个简单的远程终端协议，底层采用TCP协议。TELNET 也使用客户服务器方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程，占用端口23。4 邮件传输协议一个电子邮件系统应具如图所示的三个主要组成构件，这就是用户代理、邮件服务器，以及邮件发送协议（如SMTP ）和邮件读取协议（如POP3)， POP3 是邮局协议（Post Office Protocol）的版本3 。SMTP 和POP3 （或IMAP ）都是在TCP 连接的上面传送邮件，使用TCP 的目的是为了使邮件的传送成为可靠的。

从本节开始，我们开始学习最重要的传输层。传输层位于OSI七层模型的第四层（从下往上）。顾名思义，传输层的作用是实现应用程序间的通信。网络层的作用是保证数据在不同数据链路上传输的可达性，至于如何传输则是由传输层负责。常见的传输层协议主要有TCP和UDP协议。UDP协议最大的特点就是简单，UDP首部如图：和UDP首部相比，TCP首部要复杂的多。解析这个首部的时间也会相应的增加，这也是TCP连接的效率低于UDP的原因之一。TCP是面向有连接的协议，连接在每次通信前被建立，通信结束后被关闭。了解连接建立和关闭的过程通常是考察的重点。连接的建立和关闭可以用一张图来表示：通常情况下我们认为客户端首先发起连接请求。1.发送端发送一个SYN=1，ACK=0标志的数据包给接收端，请求进行连接，这是第一次握手；2.接收端收到请求并且允许连接的话，就会发送一个SYN=1，ACK=1标志的数据包给发送端，告诉它，可以通讯了，并且让发送端发送一个确认数据包，这是第二次握手；3.最后，发送端发送一个SYN=0，ACK=1的数据包给接收端，告诉它连接已被确认，这就是第三次握手。之后，一个TCP连接建立，开始通讯。*SYN：同步标志同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。*ACK：确认标志确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。*RST：复位标志复位标志有效。用于复位相应的TCP连接。*URG：紧急标志紧急(The urgent pointer) 标志有效。紧急标志置位，*PSH：推标志该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。*FIN：结束标志带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据根据一般思路，我们认为第三次是多余的，TCP协议为什么还要增加第三次的握手呢？这是因为在网络请求的时候，我们应该时刻记住“网络是不安全的，数据包是可能丢失的”。假设没有第三次确认，客户端向服务端发送了SYN包，请求建立连接。由于网络原因，服务器没有及时收到这个包，于是客户端重新发送了SYN包。正常建立了连接。此时超时的那个确认包到达了服务端，如果是两次握手此连接就建立了，服务端就建立了一个空连接，白白浪费资源。如果是三次，客户端判断这个确认包是无效的，就丢弃了。三次握手实际其实解决了第二步丢包问题。那么第三步的ACK包丢失了，TCP协议是如何处理的呢？按照TCP协议处理丢包问题的一般方法，服务器会重新向客户端发送确认包，知道ACK确认为止。但实际上这种做法有可能遭到SYN泛洪攻击。所谓的泛洪攻击，是指发送方伪造多个IP地址，模拟三次握手的过程。当服务器返回ACK后，攻击方故意不确认，从而使服务器不断重发ACK。由于服务器长时间处于半连接状态，最后消耗过多的CUP和内存资源导致死机。所以服务端采用的是这种方法，发送RST数据包，进入close状态，这个RST数据包中的TCP首部中的控制位中的RST位被置为1。这表示连接信息全部被初始化，原有的TCP通信不能继续。客户端如果还想建立TCP连接，需要从第一步握手重新开始。（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。

UDPUDP是面向无连接的通讯协议，UDP数据包含目的端口号和源端口号信息。主要优点速度快、操作简单、要求系统资源较少，由于通讯不需要连接，可以实现广播发送;缺点是传输数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，也不重复发送，不可靠。TCP是面向连接的通讯协议，通过三次握手建立连接，通讯完成时四次握手，主要优点是TCP在数据传输时，有确认、窗口、重传、阻塞等控制机制，能保证数据正确性，较为可靠;缺点是相对于UDP速度慢，要求系统资源较多。TCP和UDP区别：TCP是面向连接的协议，而UDP是无连接的协议，意味着当一个客户端和一个服务端通过TCP发送数据前，必须先建立连接，建立连接的过程被称为TCP三次握手;TCP提供交付保证，意味着一个使用TCP协议发送的信息是保证交付给客户端的，如果消息在传输过程中丢失，将重发;UDP是不可靠的，不提供任何交付的保证，一个数据报包在运输过程中可能会丢失;消息到达网络的另一端时可能是无序的，TCP协议将会为你排序，UDP不提供任何有序性的保证;TCP速度比较慢，而UDP速度比较快，因为TCP必须建立连接，以保证消息的可靠交付和有序性，需要做比UDP多的事;TCP是重量级的协议，UDP协议则是轻量级的协议。一个TCP数据报的报头大小最少是20个字节，UDP数据报的报头固定是8个字节。TCP报头中包含序列号，ACK号，数据偏移量，保留，控制位，窗口，紧急指针，可选项，填充项，校验位，源端口和目的端口。
TCP发送的包有序号，对方收到包后要给一个反馈，如果超过一定时间还没收到反馈就自动执行超时重发，因此TCP最大的优点是可靠。一般网页（http）、邮件（SMTP)、远程连接(Telnet)、文件(FTP)传送就用TCP UDP是面向消息的协议，通信时不需要建立连接，数据的传输自然是不可靠的，一般用于多点通信和实时的数据业务，比如语音广播、视频、QQ、TFTP(简单文件传送）、SNMP（简单网络管理协议）、RTP（实时传送协议）RIP（路由信息协议，如报告股票市场，航空信息）、DNS(域名解释）。注重速度流畅。 要了解TCP，一定要知道【三次握手，四次拜拜】，上网一搜就知道了 ，而所谓的三次握手，就是发送数据前必须建立的连接叫三次握手，握手完了才开始发的，这也就是面向连接的意思。
1、TCP是计算机网络中的传输层协议，是面向连接的 2、TCP与UDP的区别：TCP是面向连接的 而UDP是无连接的 TCP的服务是有保证的而UDP是无保证的

TCP（Transmission Control Protocol，传输控制协议），属于TCP/IP协议模型中的传输层，是基于连接的协议。TCP协议通过序列化应答和必要时重发数据包，为应用程序提供了可靠的传输流和虚拟连接服务。面向连接指的是在发送数据之前，必须与对方建立可靠的连接，就像打电话一样，你得先拨号，然后保证线路通畅，对方接听了电话，这时才能互相通话。这个建立连接的过程被称作“三次握手”。妹子：在吗？（你没有回应……）GG，你将永远失去她。妹子：在吗？（一个小时过去了）你：在这时候妹子的问题已经解决了，而你却激动地等待着她的回复。（她什么时候才能回我啊.jpg）当然这不是我们想看到的结果妹子：在吗？（第一次握手）你：在（第二次握手）妹子：问你一个问题（第三次握手）这时，她确定你在，所以会准备问问题，你也确定她在，所以激动紧张的等待没有白费接下来你们开始愉快地聊天（数据传输）终止连接的过程称之为“四次挥手”或者“四次分手”（感觉后者不太吉利，以下就用挥手）继续用刚才的微信发消息来举例：你：我讲完了， 你懂了吗？（第一次挥手）妹子：懂了，我也问完了（第二次挥手）妹子：谢谢谢，那我下了（第三次挥手）你：好，我也下了（第四次挥手）如果只有一、二、三次挥手的话，结果很容易自己想到。建立连接的三次握手，和终止连接的四次挥手，都是为了保证双方应答有效，避免让某一方持续等待接受数据而造成的资源浪费。在例子中体现为，开始聊天时不会咕咕咕，结束时不会突然去世。UDP（User Datagram Protocol，用户数据报协议），属于TCP/IP模型中的传输层，它是一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。注：传输可靠指的是，通过拥塞控制、流量控制、超时重发、丢弃重复数据等等可靠性检测手段，保证数据无差错、不丢失、不重复且按序到达。

一、TCP协议TCP位于传输层， 提供可靠的字节流服务。所谓的字节流服务（Byte Stream Service） 是指， 为了方便传输， 将大块数据分割成以报文段（segment） 为单位的数据包进行管理。 而可靠的传输服务是指， 能够把数据准确可靠地传给对方。 即TCP 协议为了更容易传送大数据才把数据分割， 而且 TCP 协议能够确认数据最终是否送达到对方。所以，TCP连接相当于两根管道（一个用于服务器到客户端，一个用于客户端到服务器），管道里面数据传输是通过字节码传输，传输是有序的，每个字节都是一个一个来传输。(1)、三次握手：握手过程中使用了 TCP 的标志（flag） —— SYN（synchronize） 和ACK（acknowledgement） 。第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN_RECV状态。第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（ACK=k+1），此包发送完毕，完成三次握手。若在握手过程中某个阶段莫名中断， TCP 协议会再次以相同的顺序发送相同的数据包。（2）、四次挥手：由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。先进行关闭的一方将执行主动关闭，而另一方被动关闭。客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。服务器B关闭与客户端A的连接，发送一个FIN给客户端A。客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。三次握手和四次挥手：在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中， B端向A端发送的ACK和FIN是分两次发送的。因为在B端接收到A端的FIN后， B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。（3）、深入理解TCP连接：由于TCP是全双工的，因此在每一个方向都必须单独关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这个方向上没有数据流动，一个TCP连接在接收到一个FIN后仍能发送数据。 首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。简单来说，是“先关读，再关写” ，总共需要4个阶段。以客户机发起关闭连接为例：1.服务器读通道关闭；2.客户端写通道关闭；3.客户端读通道关闭；4.服务器写通道关闭。关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN（finish）数据段，直到接收到对方发送的FIN,且对方收到了接收确认的ACK之后，双方的数据通信完全结束，过程中每次都需要返回确认数据段ACK。（4）、TCP使用滑动窗口机制来进行流量控制。建立连接时，各端分配一个缓冲区用来存储接收的数据，并将缓冲区的尺寸发送给另一端。接收方发送的确认消息中包含了自己剩余的缓冲区尺寸。剩余缓冲区空间的数量叫做窗口。其实就是建立连接的双虎互相知道彼此剩余的缓冲区大小。（5）、拥塞控制拥塞控制：防止过多的数据注入到网路中，这样可以使网络中的路由器或链路不至于阻塞。拥塞控制是一个全局性的过程，和流量控制不同，流量控制是点对点的控制。1、慢开始：发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态的变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接收方的接收能力，发送窗口可能小于拥塞窗口。思路就是：不要一开始就发送大量的数据，先试探一下网络的拥塞程度，也就是说由小到大增加拥塞窗口的大小。为了防止cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。 ssthresh的方法如下：当cwnd < ssthresh时，开始使用慢开始算法；当cwnd > ssthresh, 改用拥塞避免算法；当cwnd = ssthresh时，慢开始与拥塞算法任意。2.拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按照线性规律缓慢增长。无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为⽆法判定，所以都当作拥塞处理），就把慢开始门限设置为出现拥塞时的发送窗口的一半，然后把拥塞窗口设置为1，执行慢开始算法：此外，还有快速重传和快速恢复，停止-等待协议，回退N帧协议，选择重传协议等。二、UDP协议：无连接协议，也称透明协议，也位于传输层。三、两者区别：1） TCP提供面向连接的传输，通信前要先建立连接（三次握手机制）； UDP提供无连接的传输，通信前不需要建立连接。2） TCP提供可靠的传输（有序，无差错，不丢失，不重复）； UDP提供不可靠的传输。3） TCP面向字节流的传输，因此它能将信息分割成组，并在接收端将其重组； UDP是面向数据报的传输，没有分组开销。4） TCP提供拥塞控制和流量控制机制； UDP不提供拥塞控制和流量控制机制。四、长连接和短连接HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP协议是可靠的、面向连接的。在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
udp 和tcp 是 OSI 模型中的运输层中的协议。tcp 提供可靠的通信传输，而 udp 则常被用于让广播和细节控制交给应用的通信传输。两者的区别大致如下：tcp 面向连接，udp 面向非连接即发送数据前不需要建立链接；tcp 提供可靠的服务（数据传输），udp 无法保证；tcp 面向字节流，udp 面向报文；tcp 数据传输慢，udp 数据传输快； tcp 为什么要三次握手，为什么？ 我们假设A和B是通信的双方。我理解的握手实际上就是通信，发一次信息就是进行一次握手。第一次握手：A给B打电话说，你可以听到我说话吗？第二次握手：B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？第三次握手：A收到了B的信息，然后说可以的，我要给你发信息啦！在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。 注意：HTTP是基于TCP协议的，所以每次都是客户端发送请求，服务器应答，但是TCP还可以给其他应用层提供服务，即可能A、B在建立链接之后，谁都可能先开始通信。如果采用两次握手，那么只要服务器发出确认数据包就会建立连接，但由于客户端此时并未响应服务器端的请求，那此时服务器端就会一直在等待客户端，这样服务器端就白白浪费了一定的资源。若采用三次握手，服务器端没有收到来自客户端的再此确认，则就会知道客户端并没有要求建立请求，就不会浪费服务器的资源。
tcp和udp协议有什么区别? TCP（传输控制协议）和 UDP（用户数据报协议）的区别如下：1. TCP协议在传送数据段的时候要给段标号；UDP协议不需要2. TCP协议可靠；UDP协议不可靠3. TCP协议是面向连接；UDP协议采用无连接4. TCP协议负载较高，采用虚电路；UDP采用无连接5. TCP协议的发送方要确认接收方是否收到数据段（3次握手协议）6. TCP协议采用窗口技术和流控制7. TCP的速度较慢，UDP 较快。