2024年3月27日发(作者：)
TCP（Transmission Control Protocol，传输操纵协议）是面向连接的协议，
也确实是说，在收发数据前，必需和对方成立靠得住的连接。
一个TCP连接必需要通过三次“对话”才能成立起来，其中的进程超级复杂，只简单的描述
下这三次对话的简单进程：
A ---> B
2 主机B 收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据
段响应主机A,也告知主机A两件事:
我已经收到你的请求了,你可以传输数据了;你要用哪佧序列号作为起始数据段来回应我
3 主机A收到这个数据段后,再发送一个确认应答,确认已收到主机B 的数据段:"我已收到回复,我
现在要开始传输实际数据了
如此3次握手就完成了,主机A和主机B 就可以够够够够传输数据了.
3次握手的特点
没有应用层的数据
SYN这个标志位只有在TCP建产连接时才会被置1
握手完成后SYN标志位被置0
TCP断开连接要进行4次
1 当主机A完成数据传输后,将操纵位FIN置1,提出停止TCP连接的请求
2 主机B收到FIN后对其作出响应,确认这一方向上的TCP连接将关闭,将ACK置1
3 由B
端再提出反方向的关闭请求,将FIN置1
4 主机A对主机B的请求进行确认,将ACK置1,两边向的关闭终止.
由TCP的三次握手和四次断开可以看出,TCP使用面向连接的通信方式,大大提高了数据通信的可
靠性,使发送数据端
和接收端在数据正式传输前就有了交互,为数据正式传输打下了可靠的基础
名词说明
ACK TCP报头的操纵位之一,对数据进行确认.确认由目的端发出,用它来告知发送端那个序列号之
前的数据段
都收到了.比如,确认号为X,则表示前X-1个数据段都收到了,只有当ACK=1时,确认号才有效,当
ACK=0时,确认号无效,这时会要求重传数据,保证数据的完整性.
SYN 同步序列号,TCP成立连接时将那个位置1
FIN 发送端完成发送任务位,当TCP完成数据传输需要断开时,提出断开连接的一方将这位置1
UDP（User Data Protocol，用户数据报协议）
（1） UDP是一个非连接的协议，传输数据之前源端和终端不成立连接，当它想传送时就简
单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速
度仅仅是受应用程序生成数据的速度、运算机的能力和传输带宽的限制；在接收端，UDP把每一
个消息段放在队列中，应用程序每次从队列中读一个消息段。
（2）由于传输数据不成立连接，因此也就不需要珍惜连接状态，包括收发状态等，因此一台
效劳机可同时向多个客户机传输相同的消息。
（3） UDP信息包的题目很短，只有8个字节，相关于TCP的20个字节信息包的额外开销
很小。
（4）吞吐量不受拥堵操纵算法的调剂，只受应用软件生成数据的速度、传输带宽、源端和终
端主机性能的限制。
（5）UDP利用尽最大尽力交付，即不保证靠得住交付，因此主机不需要维持复杂的链接状态
表（那个地址面有许多参数）。
（6）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交
付给IP层。既不拆分，也不归并，而是保留这些报文的边界，因此，应用程序需要选择适合的报
文大小。
咱们常常利用“ping”命令来测试两台主机之间TCP/IP通信是不是正常，其实“ping”命令
的原理确实是向对方主机发送UDP数据包，然后对方主机确认收到数据包，假设是数据包是不是
抵达的消息及时反馈回来，那么网络确实是通的。
小结TCP与UDP的区别：
1.基于连接与无连接；
2.对系统资源的要求（TCP较多，UDP少）；
程序结构较简单；
4.流模式与数据报模式 ；
保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。
更多TCP和UPD的资料：
TCP---传输操纵协议,提供的是面向连接、靠得住的字节流效劳。当客户和效劳器彼此互换数
据前，必需先在两边之间成立一个TCP连接，以后才能传输数据。TCP提供超时重发，抛弃重复
数据，查验数据，流量操纵等功能，保证数据能从一端传到另一端。
UDP---用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把
应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数
据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。
UDP 与 TCP 的要紧区别在于 UDP 没必要然提供靠得住的数据传输。事实上，该协议不能保证
数据准确无误地抵达目的地。UDP 在许多方面超级有效。当某个程序的目标是尽快地传输尽可能
多的信息时（其中任意给定数据的重要性相对较低），
可利用 UDP。ICQ 短消息利用 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与UDP区别
TCP---传输操纵协议,提供的是面向连接、靠得住的字节流效劳。当客户和效劳器彼此互换数据前，必需先
在两边之间成立一个TCP连接，以后才能传输数据。TCP提供超时重发，抛弃重复数据，查验数据，流量操纵
等功能，保证数据能从一端传到另一端。
UDP---用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给
IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之
间建立一个连接，且没有超时重发等机制，故而传输速度很快
Overview
TCP (Transmission Control Protocol) is the most commonly used protocol on the Internet. The reason for this is because
TCP offers error correction. When the TCP protocol is used there is a "guaranteed delivery." This is due largely in part to
a method called "flow control." Flow control determines when data needs to be re-sent, and stops the flow of data until
previous packets are successfully transferred. This works because if a packet of data is sent, a collision may occur. When
this happens, the client re-requests the packet from the server until the whole packet is complete and is identical to its
original.
UDP (User Datagram Protocol) is anther commonly used protocol on the Internet. However, UDP is never used to send
important data such as webpages, database information, etc; UDP is commonly used for
streaming audio and video. Streaming media such as Windows Media audio files (.WMA) , Real Player (.RM), and
others use UDP because it offers speed! The reason UDP is faster than TCP is because there is no form of flow control or
error correction. The data sent over the Internet is affected by collisions, and errors will be present. Remember that UDP
is only concerned with speed. This is the main reason why streaming media is not high quality.
On the contrary, UDP has been implemented among some trojan horse viruses. Hackers develop scripts and trojans to
run over UDP in order to mask their activities. UDP packets are also used in DoS (Denial
of Service) attacks. It is important to know the difference between TCP port 80 and UDP port 80. If you don't know
what ports are go .
Frame Structure
As data moves along a network, various attributes are added to the file to create a frame. This process is called
encapsulation. There are different methods of encapsulation depending on which protocol and are being used. As a
result, the frame structure of these packets differ as well. The images below show both the TCP and UDP frame
structures.
TCP FRAME STRUCTURE
UDP FRAME STRUCTURE
The payload field contains the actually data. Notice that TCP has a more complex frame structure. This is largely due to
the fact the TCP is a connection-oriented protocol. The extra fields are need to ensure the "guaranteed delivery" offered
by TCP.
UDP
UDP 与 TCP 的主要区别在于 UDP 不一定提供可靠的数据传输。事实上，该协议不能保证数据准确无误地
到达目的地。UDP 在许多方面非常有效。当某个程序的目标是尽快地传输尽可能多的信息时（其中任意给定数
据的重要性相对较低），可使用 UDP。ICQ 短消息使用 UDP 协议发送消息。
许多程序将使用单独的TCP连接和单独的UDP连接。重要的状态信息随可靠的TCP连接发送，而主数据流
通过UDP发送。
TCP
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可靠的点对点连接将会用于绝大
多数的网络应用。
1. 明白得：窗口和滑动窗口
TCP的流量操纵
TCP利用窗口机制进行流量操纵
什么是窗口？
连接成立时，各端分派一块缓冲区用来存储接收的数据，并将缓冲区的尺寸发送给另一端
接收方发送的确认信息中包括了自己剩余的缓冲区尺寸
剩余缓冲区空间的数量叫做窗口
2. TCP的流控进程（滑动窗口）
2.
TCP 与UDP的区别
很多文章都说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是不面向连接的协议！
TCP协议和UDP协议为何会共存?
1. 大伙儿要明白，一种物理线路，单位时刻内，能够创建的“虚拟信道”是有限的！
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利用窗口机制进行流量操纵
什么是窗口？
连接成立时，各端分派一块缓冲区用来存储接收的数据，并将缓冲区的尺寸发送给另一端
接收方发送的确认信息中包括了自己剩余的缓冲区尺寸
剩余缓冲区空间的数量叫做窗口
2. TCP的流控进程（滑动窗口）
TCP(Transmission Control Protocol) 传输操纵协议
三次握手
TCP是主机对主机层的传输操纵协议，提供靠得住的连接效劳，采用三次握手确认成立一个连接:
位码即tcp标志位,有6种标示:
SYN(synchronous成立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish终止)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
客户端TCP状态迁移：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务器TCP状态迁移：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
各个状态的意义如下：
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和效劳器B进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与效劳器开始传送数据。
确认号：其数值等于发送方的发送序号 +1(即接收方期望接收的下一个序列号)。
图1 TCP三次握手成立连
接
TCP的包头结构：
源端口 16位
目标端口 16位
序列号 32位
回应序号 32位
TCP头长度 4位
reserved 6位
控制代码 6位
窗口大小 16位
偏移量
16位
校验和 16位
选项 32位(可选)
这样我们得出了TCP包头的最小长度，为20字节
•
第一次握手:
客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及初始序号X,保存在包头的序列号
(Sequence Number)字段里。
•
第二次握手:
服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)设置
为客户的I S N加1以.即X+1。
•
第三次握手.
客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发
送给对方.并且在数据段放写ISN的+1
下面是具体的例子截图：
1.此图包括两部份信息：TCP的三次握手(方框中的内容） （SYN, (SYN+ACK), ACK)
2. TCP的数据传输 （[TCP segment of a reassembled PUD])能够看出，server是将数据TCP层对消息包进行
分片传输
(1)Server端收到HTTP请求如GET以后，构造响应消息，其中携带网页内容，在server端的HTTP层发送消息
200 OK->server端的TCP层；
(2)server端的TCP层对消息包进行分片传输；
(3)client端的TCP层对接收到的各个消息包分片回送响应；
(4)client端的TCP层每次收到一部分都会用ACK确认，之后server继续传输，client继续确认，直到完成响应消
息的所有分片之后，Server发送组合HTTP响应包 200 OK，此刻在client端的消息跟踪中才能够显示HTTP 200
OK的消息包
关闭连接：
由于TCP连接是全双工的，因此每一个方向都必需单独进行关闭。那个原那么是当一方完成它的数据发送任务后就可
以够够够发送一个FIN来终止那个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在
收到一个FIN后仍能发送数据。第一进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
CP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或效劳器都可主动发起挥手
动作，在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所示。
图2 TCP四次挥手关闭连接
参见wireshark抓包，实测的抓包结果并无严格按挥手时序。我估量是时刻距离太短造成。
深切明白得TCP连接的释放：
由于TCP连接是全双工的，因此每一个方向都必需单独进行关闭。这原那么是当一方完成它的数据发送任务后就可
以够够够发送一个FIN来终止那个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接
在收到一个FIN后仍能发送数据。第一进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。
简单说来是 “先关读，后关写”，一共需要四个时期。以客户机发起关闭连接为例：
1.服务器读通道关闭
2.客户机写通道关闭
3.客户机读通道关闭
4.服务器写通道关闭
关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN（finish）数据段。直到接收到对方发送的FIN，且
对方收到了接收确认ACK之后，双方的数据通信完全结束，过程中每次接收都需要返回确认数据段ACK。
详细过程：
第一阶段 客户机发送完数据以后，向效劳器发送一个FIN数据段，序列号为i；
1.效劳器收到FIN(i)后，返回确认段ACK，序列号为i+1，关闭效劳器读通道；
2.客户机收到ACK(i+1)后，关闭客户机写通道；
（此时，客户机仍能通过读通道读取服务器的数据，服务器仍能通过写通道写数据）
第二阶段 服务器发送完数据之后，向客户机发送一个FIN数据段，序列号为j；
3.客户机收到FIN(j)后，返回确认段ACK，序列号为j+1，关闭客户机读通道；
4.效劳器收到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[$NF]} END {for(a in S) print a, S[a]}'
结果：
除ESTABLISHED，能够看到连接数比较多的几个状态是：FIN_WAIT1, TIME_WAIT, CLOSE_WAIT, SYN_RECV
和LAST_ACK；下面的文章就这几个状态的产生条件、对系统的阻碍和处置方式进行简单描述。
TCP状态
TCP状态如以下图所示：
可能有点眼花缭乱？再看看那个时序图
下面看下大伙儿一样比较关心的三种TCP状态
SYN_RECV
效劳端收到成立连接的SYN没有收到ACK包的时候处在SYN_RECV状态。有两个相关系统配置：
1， ：INTEGER
默许值是5
关于远端的连接请求SYN，内核会发送SYN ＋ ACK数据报，以确认收到上一个 SYN连接请求包。这是所谓的三
次握手( threeway handshake)机制的第二个步骤。那个地址决定内核在舍弃连接之前所送出的 SYN+ACK 数量。
不该该大于255，默许值是5，对应于180秒左右时刻。通常咱们不对那个值进行修改，因为咱们希望TCP连接不
要因为偶然的丢包而无法成立。
2，
一样效劳器都会设置来幸免SYN Flood解决。假设一个用户向效劳器发送了SYN报文后突然死机或掉线，那么
效劳器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情形下效劳器
端一样会重试（再次发送SYN+ACK给客户端）并等待一段时刻后抛弃那个未完成的连接，这段时刻的长度咱们称为
SYN Timeout，一样来讲那个时刻是分钟的数量级（大约为30秒-2分钟）。
这些处在SYNC_RECV的TCP连接称为半连接，并存储在内核的半连接队列中，在内核收到对端发送的ack包时会
查找半连接队列，并将符合的requst_sock信息存储到完成三次握手的连接的队列中，然后删除此半连接。大量
SYNC_RECV的TCP连接会致使半连接队列溢出，如尔后续的连接成立请求会被内核直接抛弃，这确实是SYN Flood
解决。
能够有效防范SYN Flood解决的手腕之一，确实是SYN Cookie。SYN Cookie原理由D. J. Bernstain和 Eric
Schenk发明。SYN Cookie是对TCP效劳器端的三次握手协议作一些修改，专门用来防范SYN Flood解决的一种
手腕。它的原理是，在TCP效劳器收到TCP SYN包并返回TCP SYN+ACK包时，不分派一个专门的数据区，而是
依照那个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP效劳器在依照那个cookie值检查那个TCP ACK
包的合法性。假设是合法，再分派专门的数据区进行处置以后的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(Max Segment Lifetime),在Windows下默以为4分钟，即240秒。TIME_WAIT
状态下的socket不能被回收利用. 具表现象是关于一个处置大量短连接的效劳器,假设是是由效劳器主动关闭客户端
的连接，将致使效劳器端存在大量的处于TIME_WAIT状态的socket， 乃至比处于Established状态下的socket
多的多,严峻阻碍效劳器的处置能力，乃至耗尽可用的socket，停止效劳。
为何需要TIME_WAIT？TIME_WAIT是TCP协议用以保证被从头分派的socket可不能受到之前残留的延迟重发报
文阻碍的机制,是必要的逻辑保证。
和TIME_WAIT状态有关的系统参数有一样由3个，本厂设置如下：
= 1
= 1
= 30
，默许60s，减小fin_timeout，减少TIME_WAIT连接数量。
= 1表示开启重用。许诺将TIME-WAIT sockets从头用于新的TCP连接，默以为0，表示关闭；
= 1表示开启TCP连接中TIME-WAIT sockets的快速回收，默以为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状态，而且这个状态要保持Maximum
Segment Lifetime的两倍时间。为什么要这样做而不是直接进入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协
议判定不同连接的依据是socket pair，于是，TCP协议就以为那个延迟的数据是属于新连接的，如此就和真正的新
连接的数据包发生混淆了。因此TCP连接还要在TIME_WAIT状态等待2倍MSL，如此能够保证本次连接的所有数
据都从网络中消失。
TCP和UDP都是传输层的协议！
应用层
（QQ）
物理连接层
各自协议使用的常用端口：如http, https, tcp, udp, ftp等等
TCP:
FTP:21, Telnet:23, SMTP:25
UDP:
DNS:53, TFTP:69, SNMP:161, RIP:520
80
http请求的详细进程
HTTP是一个应用层的协议，在那个层的协议，是一种网络交互需要遵守的一种协议标准。
一、连接：当输入一个请求时，第一成立一个socket连接，因为socket是通过ip和端口成立的，因此，之前那么
还有一个DNS解析进程。如把变成一个ip，假设是url不包括端口号，那么会利用该协议的默许端口号，HTTP协议
的默许端口号为80。
二、请求：连接成功后，开始向web效劳器发送请求，那个请求一样是GET或POST请求。
3、应答：web效劳器收到那个请求，进行处置。web效劳器会把文件内容传送给响应的web阅读器。 包括：HTTP
头信息，体信息。
4、关闭连接：当应答终止后，web阅读器与web效劳器必需断开，以保证其它web阅读器能够与web效劳器成
立连接
发布评论