TCP 详解，学习SCTP协议总结其相比TCP的优势！

一、OSI七层参考模型

#OSI把网络按照层次分为七层，由上到下分别为：

• 应用层：应用程序，通过人机交互来实现各种各样的服务，人类语言—>编码

• 表示层：编码 解码 加密 解密—>二进制

• 会话层：数据加解/密,发现 建立 维持 终止会话

• 传输层：

     1.根据端口号来拿区分不同的服务    0-65535
                       
                    静态端口号（著名端口号）1-1023
                    动态端口号    1024-65535
              
     2.提供可靠的传输—确认 重传 排序 流控
                 
              TCP 传输控制协议 面向连接的可靠传输协议
                        三次握手 四次断开
              UDP 用户数据报文协议 非面向连接的不可靠传输协议
  
     3.数据分段
              最大段长度     MSS 1480B      分割过程 少了20      传输过程
              最大传输单元   MTU 1500B       数据的封装与解封装
  

• 网络层：IP，两个版本，V4/V6–路由器，基于IP地址进行逻辑寻址

• 数据链路层：

            LLC：逻辑链路控制子层：为上层服务提供FCS校验
            MAC：媒介访问控制子层：根据mac地址来进行物理寻址
  

• 物理层：HUB，定义电气电压 接口规范 光学特性 机械定义

二、TCP报文详解

报文分析

①源端口和目的端口，各占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；服务质量，QOS

⑤紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；

⑥确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；

⑦推送PSH，当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1；

⑧复位RST，当RST=1，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接；

⑨同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；

⑩终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；

⑪窗口，占2字节，指的是通知接收方，发送本报文你需要有多大的空间来接受；

⑫检验和，占2字节，校验首部和数据这两部分；

⑬紧急指针，占2字节，指出本报文段中的紧急数据的字节数；

14 选项，长度可变，定义一些其他的可选的参数。

三、介绍TCP连接的三次握手

三次握手

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）;

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手;

补充知识：

①未连接队列

在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于SYN_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。

②TIME_WAIT状态**：TIME_WAIT状态存在有两个原因。

• <1>可靠终止TCP连接。如果最后一个ACK报文因为网络原因被丢弃，此时server因为没有收到ACK而超时重传FIN报文，处于TIME_WAIT状态的client可以继续对FIN报文做回复，向server发送ACK报文。

• <2>保证让迟来的TCP报文段有足够的时间被识别和丢弃。连接结束了，网络中的延迟报文也应该被丢弃掉，以免影响立刻建立的新连接。

追问：为什么需要三次？

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报头的一个标识位。很明显，这两步可以合并，从而提高连接的速度和效率。

四、介绍TCP断开的四次挥手

1.客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送

2.服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号

3.服务器B关闭与客户端A的连接，发送一个FIN给客户端A

4.客户端A发回ACK报文确认，并将确认序号设置为收到序号加1

为什么连接的时候是三次握手，关闭的时候却是四次握手？

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。**故需要四步握手**。

拓展问题：为什么是四次？

TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。 如果一方已经准备关闭写，但是它还可以读另一方发送的数据。发送给FIN结束报文给对方对方收到后，回复ACK报文。当这方也已经写完了准备关闭，发送FIN报文，对方回复ACK。两端都关闭，TCP连接正常关闭。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才返回到CLOSE状态？

• 网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
• 可以确保每成功建立一个TCP连接时，来自该连接先前化身的老的重复分组都已经在网络中消逝。

五、TPC的syn攻击的过程，怎么防御？

过程：syn攻击是基于TCP连接的三次握手的半连接，属于DOS攻击。攻击者发送完第一次握手后，服务器维护一个未连接队列并发送回复，但是攻击者不发送第三次握手的ack，造成服务器会等待，浪费CPU和内存，在半连接存活时间内有大量的半连接就会造成服务器无法服务现象。

防御：减小超时时间；SYN网关和SYN代理；增大最大半连接数；SYN cookies技术
SYN Cookie是对TCP服务器端的三次握手协议作一些修改，专门用来防范SYN Flood攻击的一种手段。它的原理是，在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。

• 如果可以修改协议的话可以参考SCTP的四次握手机制
• 注意：在TCP四次挥手时也是可以产生DOS攻击的

六、简述TCP协议在数据传输过程中收发双方是如何保证数据包的可靠性的?

1.为了保证数据包的可靠传递，发送方必须把已发送的数据包保留在缓冲区；
2.并为每个已发送的数据包启动一个超时定时器；
3.如在定时器超时之前收到了对方发来的应答信息（可能是对本包的应答，也可以是对本包后续包的应答），则释放该数据包占用的缓冲区;
4.否则，重传该数据包，直到收到应答或重传次数超过规定的最大次数为止。
5.接收方收到数据包后，先进行CRC校验，如果正确则把数据交给上层协议，然后给发送方发送一个累计应答包，表明该数据已收到，如果接收方正好也有数据要发给发送方，应答包也可放在数据包中捎带过去。

七、TCP是如何通过滑动窗口协议实现流量控制和拥塞控制的？

1.慢启动阶段(slow start)：发送方一开始便向网络发送多个报文段，直至达到接收方通告的窗口大小为止。当发送方和接收方处于同一个局域网时，这种方式是可以的。但是如果在发送方和接收方之间存在多个路由器和速率较慢的链路时，就有可能出现一些问题。一些中间路由器必须缓存分组，并有可能耗尽存储器的空间。

2.拥塞避免阶段congestion avoidance）：当发现超时或收到3个相同ACK确认帧时，则表示有丢包事件，此时网络已发生拥塞现象，此时要进行相应的拥塞控制。将慢启动阈值设置为当前拥塞窗口的一半；如检测到超时，拥塞窗口就被置为l。如果拥塞窗口小于或等于慢启动阈值，TCP重新进人慢启动阶段；如果拥塞窗口大于慢启动阈值，TCP执行拥塞避免算法。

3.快速重传阶段(fast retransmit)：当TCP源端收到到三个相同的ACK副本时，即认为有数据包丢失，则源端重传丢失的数据包，而不必等待RTO超时。同时将ssthresh设置为当前cwnd值的一半，并且将cwnd减为原先的一半。

4.快速恢复阶段(fast recovery) ：当”旧”数据包离开网络后，才能发送”新”数据包进入网络，即同一时刻在网络中传输的数据包数量是恒定的。如果发送方收到一个重复的ACK，则认为已经有一个数据包离开了网络，于是将拥塞窗口加1。

八、描述TCP和UDP的区别？

• TCP是基于连接的，提供可靠传输；而UDP是基于无连接的，不提供可靠传输；
• UDP报文是面向数据报文的，TCP是面向数据流的；
• UDP的报文简单，因此传输效率高；
• TCP只能提供点到点通信，但是UDP支持单播、组播和广播；

九、TCP有哪些定时器？

1.重传计时器:为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间

2.坚持计时器:专门为对付零窗口通知而设立的

3.保活计时器:每当服务器收到客户的信息，就将keeplive timer复位，超时通常设置2小时，若服务器超过2小时还没有收到来自客户的信息，就发送探测报文段，若发送了10个探测报文段（没75秒发送一个）还没收到响应，则终止连接

4.时间等待计时器:在连接终止期使用，当TCP关闭连接时，并不认为这个连接就真正关闭了，在时间等待期间，连接还处于一种中间过度状态。这样就可以时重复的fin报文段在到达终点后被丢弃，这个计时器的值通常设置为一格报文段寿命期望值的两倍。

十、SCTP协议详解：

SCTP (Stream Control Transmission Protocol)是一种传输协议，在TCP/IP协议栈中所处的位置和TCP、UDP类似，兼有TCP/UDP两者特征。
　
　　SCTP继承了TCP的诸多成熟技术，如：流控技术（滑窗技术）、动态RTO计算、拥塞控制技术等与TCP相比，同时SCTP有很多优点，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连接就还可以用。

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

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

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

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

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

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