tcp的连接采用什么方式(连接tcp失败什么意思)

目录：以前我也认为TCP是相当底层的东西，我永远不需要去了解它。虽然差不多是这样，但是实际生活中，你依然可能遇见和TCP算法相关的bug，这时候懂一些TCP的知识就至关重要了。（本文也可以引申为，系统调用，操作系统这些都很重要，这个道理适用于很多东西）这里推荐一篇小短文， 人人都应该懂点TCP使用TCP协议通信的双方必须先建立TCP连接，并在内核中为该连接维持一些必要的数据结构，比如连接的状态、读写缓冲区、定时器等。当通信结束时，双方必须关闭连接以释放这些内核数据。TCP服务基于流，源源不断从一端流向另一端，发送端可以逐字节写入，接收端可以逐字节读出，无需分段。需要注意的几点：TCP状态（11种）：eg.以上为TCP三次握手的状态变迁以下为TCP四次挥手的状态变迁服务器通过 listen 系统调用进入LISTEN状态，被动等待客户端连接，也就是所谓的被动打开。一旦监听到SYN（同步报文段）请求，就将该连接放入内核的等待队列，并向客户端发送带SYN的ACK（确认报文段），此时该连接处于SYN_RECVD状态。如果服务器收到客户端返回的ACK，则转到ESTABLISHED状态。这个状态就是连接双方能进行全双工数据传输的状态。而当客户端主动关闭连接时，服务器收到FIN报文，通过返回ACK使连接进入CLOSE_WAIT状态。此状态表示——等待服务器应用程序关闭连接。通常，服务器检测到客户端关闭连接之后，也会立即给客户端发送一个FIN来关闭连接，使连接转移到LAST_ACK状态，等待客户端对最后一个FIN结束报文段的最后一次确认，一旦确认完成，连接就彻底关闭了。客户端通过 connect 系统调用主动与服务器建立连接。此系统调用会首先给服务器发一个SYN，使连接进入SYN_SENT状态。connect 调用可能因为两种原因失败：1. 目标端口不存在（未被任何进程监听）护着该端口被TIME_WAIT状态的连接占用（ 详见后文 ）。2. 连接超时，在超时时间内未收到服务器的ACK。如果 connect 调用失败，则连接返回初始的CLOSED状态，如果调用成功，则转到ESTABLISHED状态。客户端执行主动关闭时，它会向服务器发送一个FIN，连接进入TIME_WAIT_1状态，如果收到服务器的ACK，进入TIME_WAIT_2状态。此时服务器处于CLOSE_WAIT状态，这一对状态是可能发生办关闭的状态（详见后文）。此时如果服务器发送FIN关闭连接，则客户端会发送ACK进行确认并进入TIME_WAIT状态。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。TCP 主要通过四种算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。在Linux下有多种实现，比如reno算法，vegas算法和cubic算法等。发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。为了便于讨论，做如下假设：发送的最初执行慢开始，令 cwnd=1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ...注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。如果出现了超时，则令 ssthresh = cwnd/2，然后重新执行慢开始。在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。发送端的每个TCP报文都必须得到接收方的应答，才算传输成功。TCP为每个TCP报文段都维护一个重传定时器。发送端在发出一个TCP报文段之后就启动定时器，如果在定时时间类未收到应答，它就将重发该报文段并重置定时器。因为TCP报文段最终在网络层是以IP数据报的形式发送，而IP数据报到达接收端可能是乱序或者重复的。TCP协议会对收到的TCP报文进行重排、整理，确保顺序正确。TCP报文段所携带的应用程序数据按照长度分为两种：交互数据和成块数据对于什么是粘包、拆包问题，我想先举两个简单的应用场景：对于第一种情况，服务端的处理流程可以是这样的：当客户端与服务端的连接建立成功之后，服务端不断读取客户端发送过来的数据，当客户端与服务端连接断开之后，服务端知道已经读完了一条消息，然后进行解码和后续处理...。对于第二种情况，如果按照上面相同的处理逻辑来处理，那就有问题了，我们来看看第二种情况下客户端发送的两条消息递交到服务端有可能出现的情况：第一种情况：服务端一共读到两个数据包，第一个包包含客户端发出的第一条消息的完整信息，第二个包包含客户端发出的第二条消息，那这种情况比较好处理，服务器只需要简单的从网络缓冲区去读就好了，第一次读到第一条消息的完整信息，消费完再从网络缓冲区将第二条完整消息读出来消费。第二种情况：服务端一共就读到一个数据包，这个数据包包含客户端发出的两条消息的完整信息，这个时候基于之前逻辑实现的服务端就蒙了，因为服务端不知道第一条消息从哪儿结束和第二条消息从哪儿开始，这种情况其实是发生了TCP粘包。第三种情况：服务端一共收到了两个数据包，第一个数据包只包含了第一条消息的一部分，第一条消息的后半部分和第二条消息都在第二个数据包中，或者是第一个数据包包含了第一条消息的完整信息和第二条消息的一部分信息，第二个数据包包含了第二条消息的剩下部分，这种情况其实是发送了TCP拆，因为发生了一条消息被拆分在两个包里面发送了，同样上面的服务器逻辑对于这种情况是不好处理的。我们知道tcp是以流动的方式传输数据，传输的最小单位为一个报文段（segment）。tcp Header中有个Options标识位，常见的标识为mss(Maximum Segment Size)指的是，连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit)，一般是1500比特，超过这个量要分成多个报文段，mss则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460比特。换算成字节，也就是180多字节。tcp为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。发生TCP粘包、拆包主要是由于下面一些原因：既然知道了tcp是无界的数据流，且协议本身无法避免粘包，拆包的发生，那我们只能在应用层数据协议上，加以控制。通常在制定传输数据时，可以使用如下方法：写了一个简单的 golang 版的tcp服务器实例，仅供参考：例子参考和推荐阅读书目：注释：eg.

1.采用面向连接的三次握手实现可靠对象传输。 2.使用数据窗口机制协商队列大小实现数据队列传输。3.通过序列化应答和必要时重发数据包，TCP 为应用程序提供了可靠的传输流和虚拟连接服务。下面是找到的长篇大论中比较好的文章：一、TCP协议1、TCP 通过以下方式提供可靠性：◆ 应用程序分割为TCP认为最合适发送的数据块。由TCP传递给IP的信息单位叫做报文段。◆ 当TCP发出一个报文段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能记时收到一个确认，它 就重发这个报文段。◆ 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常延迟几分之一秒。◆ TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化如果收到报文段的检验和有差错，TCP将丢弃这个报文段和不确认收到这个报文段。◆ 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能失序，因此TCP报文段的到达也可能失序。如果必要，TCP将对收到的数据进行排序，将收到的数据以正确的顺序交给应用层。◆ 既然IP数据报会发生重复，TCP连接端必须丢弃重复的数据。◆ TCP还能提供流量控制，TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。另外，TCP对字节流的内容不作任何解释。2、TCP首部：TCP数据被封装在一个IP数据报中，格式如下：IP首部20 TCP首部20 TCP首部TCP首部格式如下：16位源端口号 16位目的端口号32位序号32位确认序号4位首部长度 保留6位 URG ACK PSH RST SYN FIN 16位窗口大小16位检验和 16位紧急指针选项数据说明：（1）每个TCP段都包括源端和目的端的端口号，用于寻找发送端和接收端的应用进程。这两个值加上IP首部的源端IP地址和目的端IP地址唯一确定一个TCP连接。（2）序号用来标识从TCP发送端向接收端发送的数据字节流，它表示在这个报文段中的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。（3）当建立一个新连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN，该主机要发送数据的第一个字节的序号为这个ISN加1，因为SYN标志使用了一个序号。（4）既然每个被传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当时上次已成功收到数据字节序号加1。只有ACK标志为1时确认序号字段才有效。（5）发送ACK无需任何代价，因为32位的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。（6）TCP为应用层提供全双工的服务。因此，连接的每一端必须保持每个方向上的传输数据序号。（7）TCP可以表述为一个没有选择确认或否认的华东窗口协议。因此TCP首部中的确认序号表示发送方已成功收到字节，但还不包含确认序号所指的字节。当前还无法对数据流中选定的部分进行确认。（8）首部长度需要设置，因为任选字段的长度是可变的。TCP首部最多60个字节。（9）6个标志位中的多个可同时设置为1◆ URG－紧急指针有效◆ ACK－确认序号有效◆ PSH－接收方应尽快将这个报文段交给应用层◆ RST－重建连接◆ SYN－同步序号用来发起一个连接◆ FIN－发送端完成发送任务（10）TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收的字节数。窗口大小是一个16为的字段，因而窗口大小最大为65535字节。（11）检验和覆盖整个TCP报文端：TCP首部和TCP数据。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。TCP检验和的计算和UDP首部检验和的计算一样，也使用伪首部。（12）紧急指针是一个正的偏移量，黄蓉序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。（13）最常见的可选字段是最长报文大小MMS，每个连接方通常都在通信的第一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。二、TCP连接的建立和终止1、建立连接协议（1） 请求端发送一个SYN段指明客户打算连接的服务器的端口，隐疾初始序号(ISN)，这个SYN报文段为报文段1。（2） 服务器端发回包含服务器的初始序号的SYN报文段（报文段2）作为应答。同时将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认。一个SYN将占用一个序号。（3） 客户必须将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认（报文段3）。这3个报文段完成连接的建立，称为三次握手。发送第一个SYN的一端将执行主动打开，接收这个SYN并发回下一个SYN的另一端执行被动打开。2、连接终止协议由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。（4） 客户段发回确认，并将确认序号设置为收到序号加1（报文段7）。3、连接建立的超时如果与服务器无法建立连接，客户端就会三次向服务器发送连接请求。在规定的时间内服务器未应答，则连接失败。4、最大报文段长度MSS最大报文段长度表示TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的MSS。一般，如果没有分段发生，MSS还是越大越好。报文段越大允许每个报文段传送的数据越多，相对IP和TCP首部有更高的网络利用率。当TCP发送一个 SYN时，它能将MSS值设置为外出接口的MTU长度减去IP首部和TCP首部长度。对于以太网，MSS值可达1460。如果目的地址为非本地的，MSS值通常默认为536，是否本地主要通过网络号区分。MSS让主机限制另一端发送数据报的长度，加上主机也能控制它发送数据报的长度，这将使以较小MTU连接到一个网络上的主机避免分段。5、 TCP的半关闭TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力，这就是TCP的半关闭。客户端发送FIN，另一端发送对这个FIN的ACK报文段。当收到半关闭的一端在完成它的数据传送后，才发送FIN关闭这个方向的连接，客户端再对这个FIN确认，这个连接才彻底关闭。6、2MSL连接TIME_WAIT状态也称为2MSL等待状态。每个TCP必须选择一个报文段最大生存时间（MSL）。它是任何报文段被丢弃前在网络的最长时间。处理原则：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2MSL。这样可以让TCP再次发送最后的ACK以避免这个ACK丢失（另一端超时并重发最后的FIN）。这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口不能被使用。7、平静时间TCP在重启的MSL秒内不能建立任何连接，这就是平静时间。8、FIN_WAIT_2状态在FIN_WAIT_2状态我们已经发出了FIN，并且另一端也对它进行了确认。只有另一端的进程完成了这个关闭，我们这端才会从 FIN_WAIT_2状态进入TIME_WAIT状态。这意味着我们这端可能永远保持这个状态，另一端也将处于CLOSE_WAIT状态，并一直保持这个状态直到应用层决定进行关闭。9、复位报文段TCP首部的RST位是用于复位的。一般，无论合适一个报文端发往相关的连接出现错误，TCP都会发出一个复位报文段。主要情况：（1）到不存在的端口的连接请求；（2）异常终止一个连接。10、同时打开为了处理同时打开，对于同时打开它仅建立一条连接而不是两条连接。两端几乎在同时发送SYN，并进入SYN_SENT状态。当每一端收到SYN时，状态变为SYN_RCVD，同时他们都再发SYN并对收到的SYN进行确认。当双方都收到SYN及相应的ACK时，状态都变为ESTABLISHED。一个同时打开的连接需要交换4个报文段，比正常的三次握手多了一次。11、 同时关闭当应用层发出关闭命令，两端均从ESTABLISHED变为FIN_WAIT_1。这将导致双方各发送一个FIN，两个FIN经过网络传送后分别到达另一端。收到FIN后，状态由FIN_WAIT_1变为CLOSING，并发送最后的ACK。当收到最后的ACK，状态变为TIME_WAIT。同时关闭和正常关闭的段减缓数目相同。12、TCP选项每个选项的开始是1字节的kind字段，说明选项的类型。Kind=1:选项表结束（1字节） Kind=1:无操作（1字节） Kind=2：最大报文段长度（4字节） Kind=3:窗口扩大因子（4字节） Kind=8:时间戳（10字节）三、TCP的超时和重传对于每个TCP连接，TCP管理4个不同的定时器。（1） 重传定时器用于当希望收到另一端的确认。（2） 坚持定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口。（3） 保活定时器可检测到一个空闲连接的另一端何时崩溃或重启。（4） 2MSL定时器测量一个连接处于TIME_WAIT状态的时间。1、往返时间测量TCP超时和重传重最重要的就是对一个给定连接的往返时间（RTT）的测量。由于路由器和网络流量均会变化，因此TCP应该跟踪这些变化并相应地改变超时时间。首先TCP必须测量在发送一个带有特别序号地字节和接收到包含该字节地确认之间的RTT。2、拥塞避免算法该算法假定由于分组收到损坏引起的丢失是非常少的，因此分组丢失就意味着在源主机和目的主机之间的某处网络上发生了阻塞。有两种分组丢失的指示：发生超时和收到重复的确认。拥塞避免算法需要对每个连接维持两个变量：一个拥塞窗口cwnd和一个慢启动门限ssthresh。(1) 对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。(2) TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小。拥塞避免是发送方使用的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。(3) 当拥塞发生时，ssthresh被设置为当前窗口大小的一般(cwnd和接收方通告窗口大小的最小值，但最小为2个报文段)。此外，如果是超时引起了拥塞，则cwnd被设置为1个报文段。(4) 当新的数据被对方确认时，就增加cwnd，但增加的方法依赖与是否正在进行慢启动或拥塞避免。如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免。3、快速重传和快速恢复算法如果我们一连串收到3个或以上的重复ACK，就非常可能是一个报文段丢失了。于是我们就重传丢失的数据报文段，而无需等待超时定时器溢出。（1） 当收到第3个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半，重传丢失的报文段，设置cwnd为ssthresh加上3倍的报文段大小。（2） 每次收到另一个重复的ACK时，cwnd增加1个报文段大小并发送一个1个分组，如果允许的话。（3）当下一个确认新数据的ACK到达时，设置cwnd为ssthresh，这个ACK应该时在进行重传后的一个往返时间内对步骤1重重传的确认。另外，这个 ACK也应该是对丢失的分组和收到的第一个重复的ACK之间的所有中间报文段的确认。4、 ICMP差错TCP如何处理一个给定的连接返回的ICMP差错。TCP能够遇到的最常见的ICMP差错就是源站抑制、主机不可达和网络不可达。（1） 一个接收到的源站抑制引起拥塞窗口cwnd被置为1个报文段大小来发起慢启动，但是慢启动门限ssthresh没有变化，所以窗口将打开直到它开放了所有的通路或者发生了拥塞。（2） 一个接收到的主机不可达或网络不可达实际都被忽略，因为这两个差错都被认为是短暂现象。TCP试图发送引起该差错的数据，尽管最终有可能会超时。5、重新分组：当TCP超时并重传时，它并不一定要重传同样的报文段，相反，TCP允许进行重新分组而发送一个较大的报文段。这是允许的，因为TCP是使用字节序号而不是报文段序号来进行识别它所要发送的数据和进行确认。四、TCP的坚持定时器ACK的传输并不可靠，也就是说，TCP不对ACK报文段进行确认，TCP只确认那些包含数据的ACK报文段。为了防止因为ACK报文段丢失而双方进行等待的问题，发送方用一个坚持定时器来周期性地向接收方查询。这些从发送方发出地报文段称为窗口探查。五、TCP的保活定时器如果一个给定的连接在2小时内没有任何动作，那么服务器就向客户发送一个探查报文段。客户主机必须处于以下4个状态之一。(1) 客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方的正常工作的。服务器在2小时内将保活定时器复位。(2) 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务器将不能收到对探查的响应，并在75秒后超时。总共发送10个探查，间隔75秒。(3) 客户主机崩溃并已经重新启动。这是服务器将收到一个对其保活探查的响应，但这个响应是一个复位，使得服务器终止这个连接。(4) 客户主机正常运行，但是从服务器不可达。六、TCP的一些性能1、 路径MTU发现：TCP的路径MTU发现按如下方式进行：在连接建立时，TCP使用输出接口或对段声明的MSS中的最下MTU作为其实的报文段大小。路径MTU发现不允许TCP超过对端声明的MSS。如果对端没有指定一个MSS，则默认为536。一旦选定了起始的报文段大小，在该连接上的所有被TCP发送的IP数据报都将被设置DF位。如果中间路由器需要对一个设置了DF标志的数据报进行分片，它就丢弃这个数据报，并产生一个ICMP的“不能分片”差错。如果收到这个ICMP差错，TCP就减少段大小并进行重传。如果路由器产生的是一个较新的该类ICMP差错，则报文段大小被设置位下一跳的MTU减去 IP和TCP的首部长度。如果是一个较旧的该类ICMP差错，则必须尝试下一个可能的最小MTU。2、 长肥管道一个连接的容量＝带宽X时延（RTT）。具有大的带宽时延乘积的网络称为长肥网络（LFN）。一个运行在LFN的TCP连接称为长肥管道。管道可以被水平拉长（一个长的RTT）,或被垂直拉高（较高的带宽），或两个方向拉伸。3、窗口扩大选项：窗口扩大选项使TCP的窗口定义从16位增加到32位，这并不是通过修改TCP首部来实现的，TCP首部仍然使用16位，而是通过定义一个选项实现对16位的扩大操作来完成的。4、时间戳选项： 时间戳选项使发送方在每个报文段中放置一个时间戳值。接收方在确认中返回这个数值，从而允许发送方为每一个收到的ACK计算RTT。

TCP即传输控制协议。TCP连接是互联网连接协议集的一种。TCP通信最重要的特征是：有序和可靠。有序通过将文本流分段并编号实现,可靠通过ACK回复和重复发送实现。TCP连接状态图参考文章:TCP连接过程详解blog.163.com/hlz_2599/blog/static/142378474201151943414397/
TCP/IP(Transmission Control Protocol/Internet Protocol) 即传输控制协议/网间协议,是一个工业标准的协议集,它是为广域网(WAN)设计的。它是由ARPANET网的研究机构发展起来的。 　　有时我们将TCP/IP描述为互联网协议集"InternetProtocolSuite",TCP和IP是其中的两个协议(后面将会介绍)。由于TCP和IP是大家熟悉的协议,以至于用TCP/IP或IP/TCP这个词代替了整个协议集。这尽管有点奇怪,但没有必要去争论这个习惯。例如,有时我们讨论NFS是基于TCP/IP时,尽管它根本没用到TCP(只用到IP,和另一种交互式 协议UDP而不是TCP)。 　　TCP/IP的标准在一系列称为RFC的文档中公布。文档由技术专家、特别工作组、或RFC编辑修订。公布一个文档时,该文档被赋予一个RFC编号,如RFC959（FTP的说明文档）、RFC793（TCP的说明文档）、RFC791（IP的说明文档）等。最初的RFC一直保留而从来不会被更新,如果修改了该文档,则该文档又以一个新号码公布。因此,重要的是要确认你拥有了关于某个专题的最新RFC文档。通常在RFC的开头部分，有相关RFC的更新(update)、修改(errata)、作废（obsolete）信息，提示读者信息的时效性。
TCP/IP(Transmission Control Protocol/Internet Protocol) 即传输控制协议/网间协议,是一个工业标准的协议集,它是为广域网(WAN)设计的

传输层协议主要是：传输控制协议TCP(Transmission Control Protocol)和用户数据报协议UDP(User Datagram rotocol)。TCP是面向连接的通信协议，通过三次握手建立连接，通讯时完成时要拆除连接，由于TCP是面向连接的所以只能用于点对点的通讯。TCP提供的是一种可靠的数据流服务，采用“带重传的肯定确认”技术来实现传输的可靠性。TCP还采用一种称为“滑动窗口”的方式进行流量控制，所谓窗口实际表示接收能力，用以限制发送方的发送速度。UDP是面向无连接的通讯协议，UDP数据包括目的端口号和源端口号信息，由于通讯不需要连接，所以可以实现广播发送。UDP通讯时不需要接收方确认，属于不可靠的传输，可能会出丢包现象，实际应用中要求在程序员编程验证。
TCP协议肯定是面向连接的传输层协议。其连接过程是三次握手：连接请求、连接应答、连接确认。只有通过连接才能传输数据。传输完数据后使用四次握手断开连接；在传输层有两个协议：面向连接的传输控制协议TCP及面向非连接的用户数据报协议UDP。
TCP/IP是一个协议栈，TCP和IP只是其中的两个协议，而且正如楼上所说，它们不在同一层所以也没什么可比的。 而TCP和UDP（也是TCP/IP协议栈中的协议）是可以比较的，它们同属于传输层，一个是面向连接的，一个无连接的。还有很多差别，你可以去查资料。

TCP三次握手在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。 第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；SYN：同步序列编号(Synchronize Sequence Numbers)。 第二次握手：服务器收到syn包，必须确认客户的SYN（ac 三次握手k=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务