TCP-IP协议与UDP-IP协议的区别

TCP/IP协议与UDP/IP协议的区别TCP(TransmissionControlProtocol，传输控制协议)是面向连接的协议，也就是说，在收发数据前，必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立起来，其中的过程非常复杂，只简单的描述下这三次对话的简单过程：A-B2主机B收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A,也告诉主机A两件事：我已经收到你的请求了,你可以传输数据了;你要用哪昧序列号作为起始数据段来回应我3主机A收到这个数据段后,再发送一个确认应答，确认已收到主机B的数据段:我已收到回复，我现在要开始传输实际数据了这样3次握手就完成了，主机A和主机B就可以传输数据了.3次握手的特点没有应用层的数据SYN这个标志位只有在TCP建产连接时才会被置1握手完成后SYN标志位被置0TCP断开连接要进行4次1当主机A完成数据传输后，将控制位FIN置1,提出停止TCP连接的请求2主机B收到FIN后对其作出响应，确认这一方向上的TCP连接将关闭，将ACK置13由B端再提出反方向的关闭请求，将FIN置14主机A对主机B的请求进行确认，将ACK置1,双方向的关闭结束.由TCP的三次握手和四次断开可以看出，TCP使用面向连接的通信方式，大大提高了数据通信的可靠性,使发送数据端和接收端在数据正式传输前就有了交互,为数据正式传输打下了可靠的基础名词解释ACKTCP报头的控制位之一，对数据进行确认.确认由目的端发出，用它来告诉发送端这个序列号之前的数据段都收到了.比如，确认号为X,则表示前X-1个数据段都收到了，只有当ACK=1时，确认号才有效，当ACK=0时,确认号无效,这时会要求重传数据，保证数据的完整性.(1) SYN同步序列号，TCP建立连接时将这个位置1FIN发送端完成发送任务位，当TCP完成数据传输需要断开时，提出断开连接的方将这位置1UDP(UserDataProtocol,用户数据报协议)UDP是一个非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。(2) 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。(3) UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。(4) 吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。(5) UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表(这里面有许多参数)。(6) UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此,应用程序需要选择合适的报文大小。我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。小结TCP与UDP的区别：基于连接与无连接；对系统资源的要求（TCP较多，UDP少）；程序结构较简单；4.流模式与数据报模式；保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。更多TCP和UPD的资料：TCP-传输控制协议，提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。UDP-用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。UDP与TCP的主要区别在于UDP不一定提供可靠的数据传输。事实上，该协议不能保证数据准确无误地到达目的地。UDP在许多方面非常有效。当某个程序的目标是尽快地传输尽可能多的信息时（其中任意给定数据的重要性相对较低），可使用UDPoICQ短消息使用UDP协议发送消息。许多程序将使用单独的TCP连接和单独的UDP连接。重要的状态信息随可靠的TCP连接发送，而主数据流通过UDP发送。TCP的目的是提供可靠的数据传输，并在相互进行通信的设备或服务之间保持一个虚拟连接TCP在数据包接收无序、丢失或在交付期间被破坏时，负责数据恢复。它通过为其发送的每个数据包提供一个序号来完成此恢复。记住，较低的网络层会将每个数据包视为一个独立的单元，因此，数据包可以沿完全不同的路径发送，即使它们都是同一消息的组成部分。这种路由与网络层处理分段和重新组装数据包的方式非常相似，只是级别更高而已。为确保正确地接收数据，TCP要求在目标计算机成功收到数据时发回一个确认（即ACK）。如果在某个时限内未收到相应的ACK，将重新传送数据包。如果网络拥塞，这种重新传送将导致发送的数据包重复。但是，接收计算机可使用数据包的序号来确定它是否为重复数据包，并在必要时丢弃它。TCP与UDP的选择如果比较UDP包和TCP包的结构，很明显UDP包不具备TCP包复杂的可靠性与控制机制。与TCP协议相同，UDP的源端口数和目的端口数也都支持一台主机上的多个应用。一个16位的UDP包包含了一个字节长的头部和数据的长度，校验码域使其可以进行整体校验。（许多应用只支持UDP，如：多媒体数据流，不产生任何额外的数据，即使知道有破坏的包也不进行重发。）很明显，当数据传输的性能必须让位于数据传输的完整性、可控制性和可靠性时，TCP协议是当然的选择。当强调传输性能而不是传输的完整性时，如：音频和多媒体应用，UDP是最好的选择。在数据传输时间很短，以至于此前的连接过程成为整个流量主体的情况下，UDP也是一个好的选择，如：DNS交换。把SNMP建立在UDP上的部分原因是设计者认为当发生网络阻塞时，UDP较低的开销使其有更好的机会去传送管理数据。TCP丰富的功能有时会导致不可预料的性能低下，但是我们相信在不远的将来，TCP可靠的点对点连接将会用于绝大多数的网络应用。FTP协议即文件传输协议，它是一个标准协议,FTP协议也是应用TCP/IP协议的应用协议标准，它是在计算机和网络之间交换文件的最简单的方法。TCP-传输控制协议，提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。UDP-用户数据报协议，是一个简单的面向数据报的运输层协议UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快OverviewTCP(TransmissionControlProtocol)isthemostcommonlyusedprotocolontheInternet.ThereasonforthisisbecauseTCPofferserrorcorrection.WhentheTCPprotocolisusedthereisaguaranteeddelivery.Thisisduelargelyinparttoamethodcalledflowcontrol.Flowcontroldetermineswhendataneedstobere-sent,andstopstheflowofdatauntilpreviouspacketsaresuccessfullytransferred.Thisworksbecauseifapacketofdataissent,acollisionmayoccur.Whenthishappens,theclientre-requeststhepacketfromtheserveruntilthewholepacketiscompleteandisidenticaltoitsoriginal.UDP(UserDatagramProtocol)isanthercommonlyusedprotocolontheInternet.However,UDPisneverusedtosendimportantdatasuchaswebpages,databaseinformation,etc;UDPiscommonlyusedforstreamingaudioandvideo.StreamingmediasuchasWindowsMediaaudiofiles(.WMA),RealPlayer(.RM),andothersuseUDPbecauseitoffersspeed!ThereasonUDPisfasterthanTCPisbecausethereisnoformofflowcontrolorerrorcorrection.ThedatasentovertheInternetisaffectedbycollisions,anderrorswillbepresent.RememberthatUDPisonlyconcernedwithspeed.Thisisthemainreasonwhystreamingmediaisnothighquality.Onthecontrary,UDPhasbeenimplementedamongsometrojanhorseviruses.HackersdevelopscriptsandtrojanstorunoverUDPinordertomasktheiractivities.UDPpacketsarealsousedinDoS(DenialofService)attacks.ItisimportanttoknowthedifferencebetweenTCPport80andUDPport80.IfyoudontknowwhatportsaregohereFrameStructureAsdatamovesalonganetwork,variousattributesareaddedtothefiletocreateaframe.ThisprocessiscalledencapsulationTherearedifferentmethodsofencapsulationdependingonwhichprotocolandtopologyarebeingused.Asaresult,theframestructureofthesepacketsdifferaswell.TheimagesbelowshowboththeTCPandUDPframestructures.TCPFRAMESTRUCTURE32BITSWIDE八*八匕#1万1匚疗*51B5。SUEPORTD侦5工TZ*TTOSPORT.SEQUENCENUMBERACEMENTNUMBERSRM声EXIT-抒CrJ=SET或-AASTTJ5jiUR&EhJTPOTNTERPAVLQAD(QMTAJkjUDPFRAMESTRUCTUREThepayloadfieldcontainstheactuallydata.NoticethatTCPhasamorecomplexframestructure.ThisislargelyduetothefacttheTCPisaconnection-orientedprotocol.TheextrafieldsareneedtoensuretheguaranteeddeliveryofferedbyTCP.UDPUDP与TCP的主要区别在于UDP不一定提供可靠的数据传输。事实上，该协议不能保证数据准确无误地到达目的地UDP在许多方面非常有效。当某个程序的目标是尽快地传输尽可能多的信息时（其中任意给定数据的重要性相对较低），可使用UDPICQ短消息使用UDP协议发送消息。许多程序将使用单独的TCP连接和单独的UDP连接。重要的状态信息随可靠的TCP连接发送，而主数据流通过UDP发送。TCPTCP的目的是提供可靠的数据传输，并在相互进行通信的设备或服务之间保持一个虚拟连接。TCP在数据包接收无序、丢失或在交付期间被破坏时，负责数据恢复。它通过为其发送的每个数据包提供一个序号来完成此恢复。记住，较低的网络层会将每个数据包视为一个独立的单元，因此，数据包可以沿完全不同的路径发送，即使它们都是同一消息的组成部分。这种路由与网络层处理分段和重新组装数据包的方式非常相似，只是级别更高而已。为确保正确地接收数据，TCP要求在目标计算机成功收到数据时发回一个确认（即ACK）。如果在某个时限内未收到相应的ACK，将重新传送数据包。如果网络拥塞，这种重新传送将导致发送的数据包重复。但是，接收计算机可使用数据包的序号来确定它是否为重复数据包，并在必要时丢弃它。TCP与UDP的选择如果比较UDP包和TCP包的结构,很明显UDP包不具备TCP包复杂的可靠性与控制机制。与TCP协议相同，UDP的源端口数和目的端口数也都支持一台主机上的多个应用。一个16位的UDP包包含了一个字节长的头部和数据的长度，校验码域使其可以进行整体校验。（许多应用只支持UDP，如：多媒体数据流，不产生任何额外的数据，即使知道有破坏的包也不进行重发。）很明显，当数据传输的性能必须让位于数据传输的完整性、可控制性和可靠性时，TCP协议是当然的选择。当强调传输性能而不是传输的完整性时，如：音频和多媒体应用，UDP是最好的选择。在数据传输时间很短，以至于此前的连接过程成为整个流量主体的情况下，UDP也是一个好的选择，如：DNS交换。把SNMP建立在UDP上的部分原因是设计者认为当发生网络阻塞时，UDP较低的开销使其有更好的机会去传送管理数据。TCP丰富的功能有时会导致不可预料的性能低下，但是我们相信在不远的将来，TCP可靠的点对点连接将会用于绝大多数的网络应用。1.理解：窗口和滑动窗口TCP的流量控制TCP使用窗口机制进行流量控制什么是窗口连接建立时，各端分配一块缓冲区用来存储接收的数据，并将缓冲区的尺寸发送给另一端接收方发送的确认信息中包含了自己剩余的缓冲区尺寸剩余缓冲区空间的数量叫做窗口TCP的流控过程（滑动窗口）发送方事件接收方事件通告窗口=2500确认1000,窗口=1500确认2000,窗口=500确认2500,窗口二0应用程序读出2000字节确认窗口斗。0确认350。，窗口二1。确认4500,窗口二0应用程序读出100。字节确认4500,窗口二10。0很多文章都说TCP协议可靠，UDP协议不可靠！为什么前者可靠，后者不可靠呢既然UDP协议不可靠，为什么还要使用它呢所谓的TCP协议是面向连接的协议，面向连接是什么呢TCP和UDP都是传输层的协议！从编程的角度看，就是两个模块（模块就是代码的集合，一系列代码的组合提供相应的功能！模块化最终目的就是：分工协作！模块化好处：便于扩展开发以及维护！）。先说TCP协议：这个协议，是面向的连接！面向连接这个概念，我们要从物理层看起。大家都知道，因为“信道复用技术”的迅猛发展，才促使了计算机网络的发展！如果没有“信道复用技术”，那么单条线路上（这里的线路指物理传输介质，例如：双绞线、光纤、电话线）单位时间内只能供一台计算机使用！还是举例说明：就拿你自己的计算机来说，你跟同学“小明”聊天的时候，就不能跟另外一位同学“小强”聊天，如果你想同时跟两位同学聊天，那么你就得装两条线路！那么同时与第三位、第四位同学。第N位同学聊天的时候，你需要装几根线路全世界人民聊天的时候，又需要装几根线路“信道复用技术”实现了，在同一条线路上，单位时间内可供X台计算机同时通信！Toad知道以下几种复用技术：1、频分复用2、时分复用3、波分复用4、码分复用5、空分复用6、统计复用7、极化波复用关于“信道复用技术”更深层次的问题，需要你自己去研究！上面我们提到了“信道复用技术”！知道了这一点，我们就很容易明白“物理信道”上的“虚拟信道”概念了！不同的信道复用技术，使用不同的复用技术，目的就是创建“虚拟信道”。一个TCP协议连接其实就是在物理线路上创建的一条“虚拟信道”。这条“虚拟信道”建立后，在TCP协议发出FIN包之前（两个终端都会向对方发送一个FIN包），是不会释放的。正因为这一点，TCP协议被称为面向连接的协议！UDP协议，一样会在物理线路上创建一条“虚拟信道”，否则UDP协议无法传输数据！但是，当UDP协议传完数据后，这条“虚拟信道”就被立即注销了！因此，称UDP是不面向连接的协议！1. TCP协议和UDP协议为什么会共存大家要知道，一种物理线路，单位时间内，能够创建的“虚拟信道”是有限的！2. 使用TCP协议传输数据，当数据从A端传到B端后，B端会发送一个确认包（ACK包）给A端，告知A端数据我已收到！UDP协议就没有这种确认机制！这就是为什么说TCP协议可靠，UDP协议不可靠.QQ普通会员就是使用的UDP协议进行传输数据！既然UDP协议自身没有确认机制，这个工作可以交给应用层的进程来完成（QQ）！大家使用QQ的时候，感觉出错的几率还是非常小吧！当然，把这个确认工作完全交给QQ自身来做，就直接导致了，QQ软件体积增大！有些应用，对数据传输可靠性要求非常高，例如大家浏览网页，通过网页注册帐号、转帐等服务，这是不容许出错的，使用TCP协议能把出错的可能性降到最低（当然，网络自身很糟糕，TCP协议也没办法）。但是，提供这种可靠服务，会加大网络带宽的开销，因为“虚拟信道”是持续存在的，同时网络中还会出现大量的ACK和FIN包！因此，鱼和熊掌不可兼得，需根据实际情况选择传输协议.TCP协议提供了可靠的数据传输，但是其拥塞控制、数据校验、重传机制的网络开销很大，不适合实时通信,所以选择开销很小的UDP协议来传输数据。UDP协议是无连接的数据传输协议并且无重传机制，会发生丢包、收到重复包、乱序等情况。而对于数据精确性要求不高的状态数据以及视频数据，丢包的影响不大。因为会不断收到新的包，丢失的个别包会有新的包来覆盖,所以只需在远程控制系统的通信部分自行处理乱序及重复包的问题,而对于丢包的问题一般不作处理。但对于命令包这种需要精确收发的数据，可在程序的开发中加入丢包重发和超时丢弃的处理。当然，如果开发的是对于实时性要求不高的事件型控制命令的传输，不希望发生指令的丢失也可以直接采用TCP协议。TCP的重传机制正好适合这种情况。非面向连接的传输协议在数据传输之前不建立连接，而是在每个中间节点对非面向连接的包和数据包进行路由。没有点到点的连接，非面向连接的协议，如UDP，是不可靠的连接。当一个UDP数据包在网络中移动时，发送过程并不知道它是否到达了目的地，除非应用层已经确认了它已到达的事实。非面向连接的协议也不能探测重复的和乱序的包。标准的专业术语用“不可靠”来描述UDP。在现代网络中，UDP并不易于导致传输失败，但是你也不能肯定地说它是可靠的TCP的三次握手（建立连接）和四次挥手（关闭连接）参照：建立连接：理解：窗口和滑动窗口TCP的流量控制TCP使用窗口机制进行流量控制什么是窗口连接建立时，各端分配一块缓冲区用来存储接收的数据，并将缓冲区的尺寸发送给另一端接收方发送的确认信息中包含了自己剩余的缓冲区尺寸剩余缓冲区空间的数量叫做窗口TCP的流控过程（滑动窗口）发送方事件接收方事件通告窗3=2500确认100。，窗口=1500确认2000,窗口=500确认2500,窗口二0应用程序读出2000字节确认250。，窗口=2000确认3500,窗口二1000确认4500,窗口二0应用程序读出100。字节确认4500,窗口二1000TCP（TransmissionControlProtocol）传输控制协议三次握手TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:位码即tcp标志位，有6种标示：SYN（synchronous建立联机）ACK（acknowledgement确认）PSH（push传送）FIN（finish结束）RST（reset重置）URG（urgent紧急）Sequencenumber（顺序号码）Acknowledgenumber（确认号码）客户端TCP状态迁移：CLOSED-SYN_SENT-ESTABLISHED-FIN_WAIT_1-FIN_WAIT_2-TIME_WAIT-CLOSED服务器TCP状态迁移：CLOSED-LISTEN-SYN收到-ESTABLISHED-CLOSE_WAIT-LAST_ACK-CLOSEDB5TA01.tSHH理穿心i度命打心SYNJUCVDESTASI1SHED-主动关闭mcWAnnMCLOSE.WAIT叫J美闭）atk_一一gWL*ST_ACKTtMt_WAlT_CDOSED各个状态的意义如下:LISTEN-侦听来自远方TCP端口的连接请求;SYN-SENT-在发送连接请求后等待匹配的连接请求；SYN-RECEIVED-在收到和发送一个连接请求后等待对连接请求的确认；ESTABLISHED-代表一个打开的连接，数据可以传送给用户；FIN-WAIT-1-等待远程TCP的连接中断请求，或先前的连接中断请求的确认;FIN-WAIT-2-从远程TCP等待连接中断请求；CLOSE-WAIT-等待从本地用户发来的连接中断请求；CLOSING-等待远程TCP对连接中断的确认；LAST-ACK-等待原来发向远程TCP的连接中断请求的确认；TIME-WAIT-等待足够的时间以确保远程TCP接收到连接中断请求的确认；CLOSED-没有任何连接状态；TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接，如图1所示。（1）第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN二k），即SYN+ACK包，此时服务器B进入SYN_RECV状态。（3）第三次握手：客户端A收到服务器B的SYN+ACK包，向服务器B发送确认包ACK（ACK=k+1）,此包发送完毕，客户端A和服务器日进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据。确认号：其数值等于发送方的发送序号+1（即接收方期望接收的下一个序列号）。上机A主机B图1TCPH次握手建立连接J2bii11111111111源端口111111111111目mnftn序列号确认号菽据住部保图1R-KPS1【1server端的TCP层；server端的TCP层对消息包进行分片传输；client端的TCP层对接收到的各个消息包分片回送响应；client端的TCP层每次收到一部分都会用ACK确认，之后server继续传输，client继续确认，直到完成响应消息的所有分片之后，Server发送组合HTTP响应包200OK，此时在client端的消息跟踪中才可以显示HTTP200OK的消息包SourceCestnaiionProtocolInmTCP顷.16S.1.1D06&.131.189.62HTTPw/rrrTFTLA00.1W.189.62192.1.68.1.100TCP192.158.L.1DO202.14.15顷.158.1,1006O.1B1.139.62N5L*N5TCPTCP20Z.96.1C4.15192.LC6.L.10CW.191.1S9,&2192.L6B.1.19C5tandardqueryAww/.BNMstandarcqu匕ryresp口门字己.6亨1丘_竺里vlrci1222Ahll：pILSVNJ-5Gq=0Wn=655B5LSn=OIMS5=14IhtTjztfi，i,哽0.绍，人出=L珥JKKjg-M卢.c60.191.189.62192.L6S.L.1DOTCPTCPsegnenrfarasseinhledPDUjW.1GS.L.1D0t.2TCPihttpACKSaq-451Ack里ILFWn-65525192rL（?E.L.10CTCPITCPSEcmerTt1areassemk:ledPDUJT匚psegmerrtareasemtiledpduZIL52.153.L.DO60.191.189.62TCP2.22j-httpr*ZK丸中4丑Ack4225Win65535-60.191,109,626C.lBl.LSg.52192,156.1.1octcptcp.seyrienn:areassembledpduj193.LSS.L.1DOTCPTCPSEgTiarrtir旦gwg巨inkil旦日4DLIgBmiodHBMnBMMafM.168.1.10060DTI.189r62TCPT.422?httpACK-5eq=451Ack曲住w-=n=655/5-W.IKL.LBQ.BS-132.1-03.L.IDOHTTPHTTF/l.1200ok（?e白xr/hTnil）tc-3-c.me.TtdFarea3?enihledpdlj6O.iei.L89.6219Z.L58.L.1D0TCPACKSQ2-45：naME?a=vtTmnnMitfwwiewum.w系i_部碰关闭连接:由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。CP的连接的拆除需要发送四个包，因此称为四次挥手(four-wayhandshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。(1) 客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。(2) 服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN-样，一个FIN将占用一个序号。(3) 服务器B关闭与客户端A的连接，发送一个FIN给客户端A。(4) 客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。TCP采用四次挥手关闭连接如图2所示。(sign：ACK=lHFINl)图2TCP四次挥手关闭连接参见wireshark抓包，实测的抓包结果并没有严格按挥手时序。我估计是时间间隔太短造成。深入理解TCP连接的释放：由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。简单说来是“先关读，后关写”，一共需要四个阶段。以客户机发起关闭连接为例：服务器读通道关闭客户机写通道关闭客户机读通道关闭服务器写通道关闭关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN(finish)数据段。直到接收到对方发送的FIN，且对方收到了接收确认ACK之后，双方的数据通信完全结束，过程中每次接收都需要返回确认数据段ACK。详细过程：1. 第一阶段客户机发送完数据之后，向服务器发送一个FIN数据段，序列号为i；服务器收到FIN(i)后，返回确认段ACK，序列号为i+1,关闭服务器读通道；客户机收到ACK(i+1)后，关闭客户机写通道；(此时，客户机仍能通过读通道读取服务器的数据，服务器仍能通过写通道写数据)第二阶段服务器发送完数据之后，向客户机发送一个FIN数据段，序列号为j；客户机收到FIN(j)后，返回确认段ACK，序列号为j+1,关闭客户机读通道；服务器收到ACK(j+1)后，关闭服务器写通道。这是标准的TCP关闭两个阶段，服务器和客户机都可以发起关闭，完全对称。FIN标识是通过发送最后一块数据时设置的，标准的例子中，服务器还在发送数据，所以要等到发送完的时候，设置FIN(此时可称为TCP连接处于半关闭状态，因为数据仍可从被动关闭一方向主动关闭方传送)。如果在服务器收到FIN(i)时,已经没有数据需要发送，可以在返回ACK(i+1)的时候就设置FIN(j)标识，这样就相当于可以合并第二步和第三步。读Linux网络编程关闭TCP连接章节，作以下笔记：“先关读，后关写”这句话大神是有别的理解吗？按道理来说，发送方不写，接受方收到发送方不写后不读。这样才更好保证，已发的都能收到，不发的之后不再发。我理解来应该是先关写后关读才对。而且对于楼主的那个http请求的抓包实验，我想到的一点拙见：对于tcp的两端而言，我关我的写端，你关你的写端。http协议的一般特殊性，一请求一应答。所以服务端收到客户端请求之后，已经决定不再有后续通信，所以写完的回复之后立即关闭。客户端收到服务器回复后也几乎同时收到了服务端作为发送方时的关闭写端。这才表现出了这个tcp的关闭时序跟你解释的有出入。关闭写端也是需要发送的tcp数据。感觉有几个地方说的太误导人。其一：客户机发起关闭连接为例，为什么不是客户端先关闭写通道，服务器后关闭读通道？其二：对于CLOSE_WAIT状态的描述是错的。原文说“被动关闭的server收到FIN后，但未发出ACK的TCP状态是CLOSE_WAIT”。应该是被动关闭端未发出FIN的TCP状态是CLOASE_WAIT。通常服务器收到FIN消息，不管什么情况都会立马发送ACK确认的。如果按原文说的未发出ACK是CLOSE_WAIT状态。那么相信CLOSE_WAIT状态将很少看到TCP的TIME_WAIT和Close_Wait状态面试时看到应聘者简历中写精通网络，TCP编程，我常问一个问题，TCP建立连接需要几次握手95%以上的应聘者都能答对是3次。问TCP断开连接需要几次握手，70%的应聘者能答对是4次通讯。再问CLOSE_WAIT，TIME_WAIT是什么状态，怎么产生的，对服务有什么影响，如何消除有一部分同学就回答不上来。不是我扣细节，而是在通讯为主的前端服务器上，必须有能力处理各种TCP状态。比如统计在本厂的一台前端机上高峰时间TCP连接的情况，统计命令：netstat-n|awk/tcp/+S$NFENDfor(ainS)printa,Sa结果：TCF我新连接数TIME_WAIT1443CLOSE_WAIT1122SN_SENT3FINJVA1T12074FIN_WAIT2195ESTABLISHED89782SN_RECV7314CLOSING9UST_ACK2372除了ESTABLISHED,可以看到连接数比较多的几个状态是：FIN_WAIT1,TIME_WAIT,CLOSE_WAIT,SYN_RECV和LAST_ACK；下面的文章就这几个状态的产生条件、对系统的影响以及处理方式进行简单描述。TCP状态TCP状态如下图所示:可能有点眼花缭乱再看看这个时序图Cli&ntServersend5YNSYNSENTemiveSYN+ACKESTABLISHEDLISTENecEiveSYNSYh_RECVSYN孑ACKsenteceiv匕ACKESTABLISHEDTCPsessionFINFINWATT1Merz璋ACKFIN.WAIT2receiveFINTIME_WAITs巳ndACKTFgOutCLOSED旧匚由丫巳FINCLOSE_WAITice扣伫ACK巳匚eiueFINLASTACK伦曲匹ACKCLOSEDhttp;/hi.baidu.oin/inilj.dapeng下面看下大家一般比较关心的三种TCP状态SYN_RECV服务端收到建立连接的SYN没有收到ACK包的时候处在SYN_RECV状态。有两个相关系统配置:1，:INTEGER默认值是5对于远端的连接请求SYN,内核会发送SYN+ACK数据报，以确认收到上一个SYN连接请求包。这是所谓的三次握手（threewayhandshake）机制的第二个步骤。这里决定内核在放弃连接之前所送出的SYN+ACK数目。不应该大于255,默认值是5,对应于180秒左右时间。通常我们不对这个值进行修改，因为我们希望TCP连接不要因为偶尔的丢包而无法建立。2,般服务器都会设置来防止SYNFlood攻击。假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYNTimeout，般来说这个时间是分钟的数量级（大约为30秒-2分钟）。这些处在SYNC_RECV的TCP连接称为半连接，并存储在内核的半连接队列中，在内核收到对端发送的ack包时会查找半连接队列，并将符合的requst_sock信息存储到完成三次握手的连接的队列中，然后删除此半连接。大量SYNC_RECV的TCP连接会导致半连接队列溢出，这样后续的连接建立请求会被内核直接丢弃，这就是SYNFlood攻击。能够有效防范SYNFlood攻击的手段之一，就是SYNCookieoSYNCookie原理由D.J.Bernstain和EricSchenk发明。SYNCookie是对TCP服务器端的三次握手协议作一些修改，专门用来防范SYNFlood攻击的一种手段。它的原理是，在TCP服务器收到TCPSYN包并返回TCPSYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCPACK包时，TCP服务器在根据那个cookie值检查这个TCPACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。观测服务上SYN_RECV连接个数为：7314,对于一个高并发连接的通讯服务器，这个数字比较正常。CLOSE_WAIT发起TCP连接关闭的一方称为client，被动关闭的一方称为server。被动关闭的server收到FIN后，但未发出ACK的TCP状态是CLOSE_WAIT。出现这种状况一般都是由于server端代码的问题，如果你的服务器上出现大量CLOSE_WAIT，应该要考虑检查代码。TIME_WAIT根据TCP协议定义的3次握手断开连接规定，发起socket主动关闭的一方socket将进入TIME_WAIT状态。TIME_WAIT状态将持续2个MSL(MaxSegmentLifetime),在Windows下默认为4分钟，即240秒。TIME_WAIT状态下的socket不能被回收使用.具体现象是对于一个处理大量短连接的服务器，如果是由服务器主动关闭客户端的连接，将导致服务器端存在大量的处于TIME_WAIT状态的socket，甚至比处于Established状态下的socket多的多，严重影响服务器的处理能力，甚至耗尽可用的socket，停止服务。为什么需要TIME_WAITTIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制，是必要的逻辑保证。和TIME_WAIT状态有关的系统参数有一般由3个，本厂设置如下：=1=1=30，默认60s，减小fin_timeout，减少TIME_WAIT连接数量。=1表示开启重用。允许将TIME-WAITsockets重新用于新的TCP连接，默认为0,表示关闭;=1表示开启TCP连接中TIME-WAITsockets的快速回收，默认为0,表示关闭。为了方便描述，我给这个TCP连接的一端起名为Client，给另外一端起名为Server。上图描述的是Client主动关闭的过程，FTP协议中就这样的。如果要描述Server主动关闭的过程，只要交换描述过程中的Server和Client就可以了，HTTP协议就是这样的。描述过程：Client调用close()函数，给Server发送FIN，请求关闭连接；Server收到FIN之后给Client返回确认ACK，同时关闭读通道(不清楚就去看一下shutdown和close的差别)，也就是说现在不能再从这个连接上读取东西，现在read返回0。此时Server的TCP状态转化为CLOSE_WAIT状态。Client收到对自己的FIN确认后，关闭写通道，不再向连接中写入任何数据。接下来Server调用close()来关闭连接，给Client发送FIN，Client收到后给Server回复ACK确认，同时Client关闭读通道，进入TIME_WAIT状态。Server接收到Client对自己的FIN的确认ACK，关闭写通道，TCP连接转化为CLOSED，也就是关闭连接。Client在TIME_WAIT状态下要等待最大数据段生存期的两倍，然后才进入CLOSED状态，TCP协议关闭连接过程彻底结束。以上就是TCP协议关闭连接的过程，现在说一下TIME_WAIT状态。从上面可以看到，主动发起关闭连接的操作的一方将达到TIME_WAIT状态，而且这个状态要保持MaximumSegmentLifetime的两倍时间。为什么要这样做而不是直接进入CLOSED状态原因有二：一、保证TCP协议的全双工连接能够可靠关闭二、保证这次连接的重复数据段从网络中消失先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socketpair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。TCP和UDP都是传输层的协议！应用层（QQ）物理连接层各自协议使用的常用端口：如http,https,tcp,udp,ftp等等TCP:FTP:21,Telnet:23,SMTP:25UDP:DNS:53,TFTP:69,SNMP:161,RIP:52080http请求的详细过程HTTP是一个应用层的协议，在这个层的协议，是一种网络交互需要遵守的一种协议规范。1、连接：当输入一请求时，首先建立一个socket连接，因为socket是通过ip和端口建立的，所以，之前则还有一个DNS解析过程。如把变成一个ip，如果url不包含端口号，则会使用该协议的默认端口号，HTTP协议的默认端口号为802、请求：连接成功后，开始向web服务器发送请求，这个请求一般是GET或POST请求。3、应答：web服务器收到这个请求，进行处理web服务器会把文件内容传送给响应的web浏览器。包括：HTTP头信息，体信息。4、关闭连接：当应答结束后，web浏览器与web服务器必须断开，以保证其它web浏览器能够与web服务器建立连接