TCP头部

最新推荐文章于 2024-03-22 00:12:09 发布

xXbB.pP

最新推荐文章于 2024-03-22 00:12:09 发布

阅读量387

点赞数

分类专栏：网络文章标签：网络网络通信

原文链接：https://blog.csdn.net/scutzxb_2/article/details/52717392?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-4.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-4.nonecase

版权

网络专栏收录该内容

4 篇文章 0 订阅

订阅专栏

标题TCP：传输控制协议

面向连接的可靠传输协议 --在完成了传输层基本工作的基础上还需要保证传输的可靠性
面向连接：传输数据前先通过三次握手建立端到端的虚链路
可靠传输：4种可靠传输机制排序、确认、重传、流控（滑动窗口机制）

在这里插入图片描述
8Bit=1字节
从上到下依次是
16位源端口 16位目标端口
32位序列号排序作用
32位确认号确认作用
4位报头长度、预留位（qos服务质量） 16位窗口大小
16位TCP校验和 16位紧急指针

源端口和目标端口：各占2个字节，分别写入源端口和目标端口；
序列号：占4个字节，TCP连接中传送的字节流中的每个字节都按顺序编号。例如，一段报文的序号字段值是 301 ，而携带的数据共有100字段，显然下一个报文段（如果还有的话）的数据序号应该从401开始；
确认号：占4个字节，是期望收到对方下一个报文的第一个数据字节的序号。例如，B收到了A发送过来的报文，其序列号字段是501，而数据长度是200字节，这表明B正确的收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701；
数据偏移（报头长度）：占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远；
保留位：占6位，保留今后使用，但目前应都位0；
（1）紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；
（2）确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；
（3）推送PSH，当两个应用进程进行交互式通信时，有时在一端的应用进程希望在进入一个命令后立即就能收到对方的响应，这时候就将PSH=1；
（4）复位RST，当RST=1，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接；
（5）同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；
（6）终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；
窗口：占2字节，指的是通知接收方，发送本报文你需要有多大的空间来接受；
检验和：占2字节，校验首部和数据这两部分；
紧急指针：占2字节，指出本报文段中的紧急数据的字节数；
选项：长度可变，定义一些其他的可选的参数。

tcp的三次握手

TCP是可靠的传输控制协议，三次握手能保证数据可靠传输又能提高传输效率。

三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的
在这里插入图片描述

第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）;
第二次握手：服务器收到syn包，必须确认客户的ACK（ack=x+1），同时自己也发送一个SYN包（seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手;

四次断开

在这里插入图片描述

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于CLOSE_WAIT状态。
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

面试题

为什么需要三次？

TCP是可靠的传输控制协议，三次握手能保证数据可靠传输又能提高传输效率。
如果TCP的握手是两次：
<1>如果client发给server的SYN报文因为网络原因，延迟发送。由于client没有收到server对SYN的确认报文，会重发SYN报文，服务器和回复ACK，连接建立。数据发送完毕，这条连接被正常关闭。这时，延迟的SYN报文发到了server，server误以为这是client重新发送的同步报文，又回复了一个ACK，和client建立了连接。
<2>如果server给client发送的ACK报文因为网络原因，报文被丢弃，此时server认为已经建立好连接，但是client没有收到确认报文，认为没有建立好连接。client会重发SYN报文，此时server已经处于就绪状态，认为已经建立好连接。

如果TCP的握手是四次：
–1.client给server发送SYN同步报文；
–2.server收到SYN后，给client回复ACK确认报文；
–3.server给client发送SYN同步报文；
–4.client给server发送ACK确认报文。
第2.3步之间，server和client没有任何的数据交互，分开发送相当于多发了一次TCP报文段，SYN和ACK标识只是TCP报头的一个标识位。很明显，这两步可以合并，从而提高连接的速度和效率。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当服务器端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务器端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
追问：为什么是四次？
TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。如果一方已经准备关闭写，但是它还可以读另一方发送的数据。发送给FIN结束报文给对方对方收到后，回复ACK报文。当这方也已经写完了准备关闭，发送FIN报文，对方回复ACK。两端都关闭，TCP连接正常关闭。
为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
• 网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
• 可以确保每成功建立一个TCP连接时，来自该连接先前化身的老的重复分组都已经在网络中消逝。

MSL

MSL全称是maximum segment lifetime，最长分节生命期。MSL是任何IP数据报能够在因特网存活的最长时间。我们知道，这个时间是有限的，因为每个数据报都含有一个限跳（hop limit）的8位字段，它的最大值是255（简单的讲就是不同经过超过255个路由器）。尽管这个跳数限制而不是真正的时间限制，我们仍然假设最大限跳的分组在网络中存在的时间不可能超过MSL秒。
MSL的具体值通常为30秒或者是2分钟。

SCTP流控制传输协议

sctp原文链接
SCTP提供的服务与TCP，UDP类似，或者甚至可以理解为其是TCP与UDP协议各自优点的组合后的产物。SCTP是可以确保数据传输的，和TCP类似，也是通过确认机制来实现的。

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的接收端都能重新组包，并通知应用程序去接收。

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

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

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

在这里插入图片描述

体现在socket API中，TCP只能bind一个IP，而SCTP可以bind到多个IP。

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

一条SCTP连接里面，可以区分多条不同的流（stream），不同的流之间的数据传输互不干扰。这样做理论上的好处是，如果其中某一条流由于丢包阻塞了，那只会影响到这一条流，其他的流并不会被阻塞。但是实际上，如果某一条流由于丢包阻塞，其他的流通常也会丢包，被阻塞，最后导致所有的流都被阻塞，SCTP连接中断。
在这里插入图片描述
在同一条stream里面，SCTP支持有序/无序两种传输方式，应用程序在调用sendmsg()的时候，需要指定用哪一条stream传输，以及指定这条要发送的消息是需要有序传输还是无序传输的。如果在传输过程中丢包，则有序传递模式可能会在接收端被阻塞，而无序传输模式不会在接收端被阻塞。

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端。

SCTP有heartbeat机制来管理路径的可用性

SCTP协议本身有heartbeat机制来监控连接/路径的可用性。

前面说过，SCTP两端都可以bind多个IP，因此同一条SCTP连接的数据可以采用不同的IP来传输。不同的IP传输路径对应一条path，不同的path都可以由heartbeat或者是数据的传输/确认来监控其状态。

如果heartbeat没相应，或者是数据在某条path超时没收到确认导致重传，则认为该path有一次传输失败。如果该path的连续传输失败次数超过path的连续重传次数，则认为该path不可用，并通知应用程序。如果一条连接的连续传输次数超过设定的“连接最大重传次数”，则该连接被认为不可用，该连接会被关闭并通知应用程序。