TCP协议 STCP与TCP比较

可靠性是计算机系统的基础应用程序信赖于底层计算机系统数据 的可靠传 输，系统保证数据传送到底层后不会丢失和重复。保证端对端数据传输的可靠 性 ，是通过传输层来实现的。

传输层定义了主机应用程序之间端到端的连通性。传输层中最为常见的两个协议分别是传输控制协议TCP（Transmission Control Protocol）和用户数据包协议UDP（User Datagram Protocol）。

面向连接就是在正式通信前必须要与对方建立起连接。比如你给别人打电话，必须等线路接通了、对方拿起话筒才能相互通话。
面向无连接是在正式通信前不必与对方先建立连接，不管对方状态就直接发送。面向无连接是在每个中间节点对非面向连接的包和数据包进行路由。比如发送手机短信，当你发短信的时候，只需要输入对方手机号而不必在意对方是否确认接收。
TCP使一个面向连接的协议，他需要两个端点都同意连接才能进行通信。在TCP进行互联网络通信之前，连接双方的应用程序必须建立连接。采用客户及服务模式建立这种连接，客户方应用程序主动打开请求，通知操作系统要建立一个连接，服务方应用程序通知操作系统，希望建立一个输入的连接，即被动打开的功能。连接建立好后，应用程序开始进行数据传输。
TCP（传输控制协议）属于面向连接的网络协议
TCP是一种面向连接的传输层协议，可提供可靠的传输服务。
1.传输控制协议（TCP）面向连接，可靠传输 流控及窗口机制
2.使用TCP的应用：WEB浏览器，电子邮件；文件传输程序

tcp端口号
端口号用来区分不同的网络服务
TCP允许一个主机同时运行多个应用进程。每台主机可以拥有多个应用端口，每对端口号、源和目标IP地址的组合唯一地标识了一个会话。端口分为知名端口和动态端口。有些网络服务会使用固定的端口，这类端口称为知名端口，端口号范围为0-1023。如FTP、HTTP、Telnet、SNMP服务均使用知名端口。动态端口号范围从1024到65535，这些端口号一般不固定分配给某个服务，也就是说许多服务都可以使用这些端口。只要运行的程序向系统提出访问网络的申请，那么系统就可以从这些端口号中分配一个供该程序使用。

TCP报文：
TCP头部
TCP通常使用IP作为网络层协议，这时TCP数据段被封装在IP数据包内。
TCP数据段由TCP Header（头部）和TCP Data（数据）组成。TCP最多可以有60个字节的头部，如果没有Options字段，正常的长度是20字节。
TCP Header是由如上图标识的一些字段组成，这里列出几个常用字段。
16位源端口号：源主机的应用程序使用的端口号。
16位目的端口号：目的主机的应用程序使用的端口号。每个TCP头部都包含源和目的端的端口号，这两个值加上IP头部中的源IP地址和目的IP地址可以唯一确定一个TCP连接。
32位序列号：用于标识从发送端发出的不同的TCP数据段的序号。数据段在网络中传输时，它们的顺序可能会发生变化；接收端依据此序列号，便可按照正确的顺序重组数据。
32位确认序列号：用于标识接收端确认收到的数据段。确认序列号为成功收到的数据序列号加1。
4位头部长度：表示头部占32bit字的数目，它能表达的TCP头部最大长度为60字节。
16位窗口大小：表示接收端期望通过单次确认而收到的数据的大小。由于该字段为16位，所以窗口大小的最大值为65535字节，该机制通常用来进行流量控制。
16位校验和：校验整个TCP报文段，包括TCP头部和TCP数据。该值由发送端计算和记录并由接收端进行验证。

TCP三次握手
TCP是一种可靠的，面向连接的全双工传输层协议。
TCP连接的建立是一个三次握手的过程[3]。如图所示：
主机A（通常也称为客户端）发送一个标识了SYN的数据段，表示期望与服务器A建立连接，此数据段的序列号（seq）为a。
服务器A回复标识了SYN+ACK的数据段，此数据段的序列号（seq）为b，确认序列号为主机A的序列号加1（a+1），以此作为对主机A的SYN报文的确认。
主机A发送一个标识了ACK的数据段，此数据段的序列号（seq）为a+1，确认序列号为服务器A的序列号加1（b+1），以此作为对服务器A的SYN报文的确认。

TCP传输过程

TCP的可靠传输还体现在TCP使用了确认技术来确保目的设备收到了从源设备发来的数据，并且是准确无误的[4]。
确认技术的工作原理如下：
目的设备接收到源设备发送的数据段时，会向源端发送确认报文，源设备收到确认报文后，继续发送数据段，如此重复[5]。
如图所示，主机A向服务器A发送TCP数据段，为描述方便假定每个数据段的长度都是500个字节。当服务器A成功收到序列号是M+1499的字节以及之前的所有字节时，会以序列号M+1499+1=M+1500进行确认。另外，由于数据段N+3传输失败，所以服务器A未能收到序列号为M+1500的字节，因此服务器A还会再次以序列号M+1500进行确认。

TCP流量控制
TCP滑动窗口技术通过动态改变窗口大小来实现对端到端设备之间的数据传输进行流量控制。
如图所示，主机A和服务器A之间通过滑动窗口来实现流量控制。为方便理解，此例中只考虑主机A发送数据给服务器A时，服务器A通过滑动窗口进行流量控制。
主机A向服务器发送4个长度为1024字节的数据段，其中主机的窗口大小为4096个字节。服务器A收到第3个数据段后，缓存区满，第4个数据段被丢弃。服务器以ACK 3073响应，窗口大小调整为3072，表明服务器的缓冲区只能处理3072个字节的数据段。于是主机A改变其发送速率，发送窗口大小为3072的数据段。

TCP断开连接
主机在关闭连接之前，要确认收到来自对方的ACK。
TCP支持全双工模式传输数据，这意味着同一时刻两个方向都可以进行数据的传输。在传输数据之前，TCP通过三次握手建立的实际上是两个方向的连接，因此在传输完毕后，两个方向的连接必须都关闭。
TCP连接的建立是一个三次握手的过程，而TCP连接的终止则要经过四次握手。
如图所示：
主机A想终止连接，于是发送一个标识了FIN，ACK的数据段，序列号为a，确认序列号为b。
服务器A回应一个标识了ACK的数据段，序列号为b，确认序号为a+1，作为对主机A的FIN报文的确认。
服务器A想终止连接，于是向主机A发送一个标识了FIN，ACK的数据段，序列号为b，确认序列号为a+1。
主机A回应一个标识了ACK的数据段，序列号为a+1，确认序号为b+1，作为对服务器A的FIN报文的确认。
以上四次交互便完成了两个方向连接的关闭。

TCP窗口机制
窗口大小 决定了在收到确 认前可以发送的字节数
确认号 是期望接收的下一 个TCP segment的序列号
握手为什么需要三次
TCP传输控制协议 称为面向连接的可靠传输协议
先来说一下三次握手的目的：
第一次握手是客户端发送SYN，服务端收到了。得出结论客服端的发送能力和服务端的接收能力正常。
第二次握手服务端发SYN,ACK，客户端收到了SYN。得出结论：服务端的接收、发送能力 和客户端的发送能力均正常。此时服务端还不能确定客户端的接收能力是否正常。
第三次握手：客户端发ACK，服务端收到了。这时候服务端就得出结论，客户端的接收功能也正常。
因此，需要三次握手才能确认双方的接收与发送能力是否正常。‘

为什么要进行三次握手?
3次握手完成两个重要的功能，要双方都做好发送数据的准备工作，且双方都要知道对方准备好了，同时也要双方对初始序列号进行协商，序列号在握手过程中被发送和确认。
如果客户端发出连接请求，因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到确认，建立了连接。数据传输完毕后，就释放了连接。客户端共发了两个连接请求报文段，其中第一个丢失，第二个到达。但是第一个只是在某些网络结点长时间滞留了，延误到连接释放后某个时间到达服务端，此时服务端误认为是客户端又发出的新的连接请求，于是发送确认，同意连接。不采用三次握手，只要客户端发送确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发数据，则服务端一直等待客户端发送数据，就会造成资源浪费。

为什么断开需要四次，三次不行吗？
这是由TCP的半关闭造成的，半关闭就是TCP提供了连接的一端在结束发送后还能接收来自另一端数据的能力。
需要断开时，首先客户端发送SYN请求，当服务端接到客户端的SYN请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是在关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭，所以只能先回复一个ACK报文，告诉客户端，收到了FIN报文。只有等到服务端所有报文都发送完了，服务端才发送FIN报文，因此不能同时发送。等客户端收到了服务端发送的FIN报文后在发送ACK报文给服务端，最后断开连接。故需要四次断开。

以下为转载：
SCTP 是一种传输协议，在TCP/IP协议栈中所处的位置和TCP、UDP类似，兼有TCP/UDP两者特征。
SCTP是可以确保数据传输的，和TCP类似，也是通过确认机制来实现的。和TCP不同的是：

1. TCP是以字节为单位传输的，SCTP是以数据块为单位传输的

TCP接收端确认的是收到的字节数，SCTP接收端确认的是接收到的数据块。SCTP的这种数据块（被称为DATA CHUNK）通常会携带应用的一个数据包，或者说是应用要发送的一个消息。

在实际的应用中，TCP发送方的可以将应用程序需要发送的多个消息打包到一个TCP包里面发出去。比如，应用程序连续调用两次send()向对端发送两条消息，TCP协议可能把这两条消息都打包放在同一个TCP包中。接收端在收到这个TCP包时，回给对端的ACK只是表明自己接收到了多少个字节，TCP协议本身并不会把收到的数据重新拆散分成两条应用层消息并通知应用程序去接收。事实上，应用程序可能只需要调用一次receive()，就会把两条消息都收上来，然后应用需要根据应用程序自己定义的格式去拆成两条消息。

与TCP不同，SCTP是将应用程序的每次调用sendmsg()发送的数据当作一个整体，放到一个被称为DATA CHUNK的数据块里面，接收端也是以DATA CHUNK为单位接收数据，并重新组包，通知应用程序接收。通常，应用程序每次调用recvmesg()都会收到一条完整的消息。

在SCTP的发送端，多条短的应用层消息可以被SCTP协议打包放在同一个SCTP包中，此时在SCTP包中可以看到多个DATA CHUNK。另一方面，一条太长（比如，超过了路径MTU）的应用层消息也可能被SCTP协议拆分成多个片段，分别放在多个DATA CHUNK并通过不同的SCTP包发送给对端。这两种情况下，SCTP的接收端都能重新组包，并通知应用程序去接收。

2. TCP通常是单路径传输，SCTP可以多路径传输

TCP的两端都只能用一个IP来建立连接，连接建立之后就只能用这一对IP来相互收发消息了。如果这一对IP之间的路径出了问题，那这条TCP连接就不可用了。

SCTP不一样的地方是，两端都可以绑定到多个IP上，只要有其中一对IP能通，这条SCTP连接就还可以用。

3. TCP是单流有序传输，SCTP可以多流独立有序/无序传输

一条SCTP连接里面，可以区分多条不同的流（stream），不同的流之间的数据传输互不干扰。这样做理论上的好处是，如果其中某一条流由于丢包阻塞了，那只会影响到这一条流，其他的流并不会被阻塞。但是实际上，如果某一条流由于丢包阻塞，其他的流通常也会丢包，被阻塞，最后导致所有的流都被阻塞，SCTP连接中断。

在同一条stream里面，SCTP支持有序/无序两种传输方式，应用程序在调用sendmsg()的时候，需要指定用哪一条stream传输，以及指定这条要发送的消息是需要有序传输还是无序传输的。如果在传输过程中丢包，则有序传递模式可能会在接收端被阻塞，而无序传输模式不会在接收端被阻塞。
4. TCP连接的建立过程需要三步握手，SCTP连接的建立过程需要四步握手

TCP连接建立过程，容易受到DoS攻击。在建立连接的时候，client端需要发送SYN给server端，server端需要将这些连接请求缓存下来。通过这种机制，攻击者可以发送大量伪造的SYN包到一个server端，导致server端耗尽内存来缓存这些连接请求，最终无法服务。

SCTP的建立过程需要四步握手，server端在收到连接请求时，不会立即分配内存缓存起来，而是返回一个COOKIE。client端需要回送这个COOKIE，server端校验之后，从cookie中重新获取有效信息（比如对端地址列表），才会最终建立这条连接。这样，可以避免类似TCP的SYN攻击。

应用程序对此感知不到，对应用程序来说，不管是TCP还是SCTP，都只需要在server端listen一个socket，client调用connect()去连接到一个server端。