tcp连接标识(tcp flags 标识)

可通过ip+端口号确定唯一的连接，ip在ip报里，端口号在tcp/udp包里
TCP是通过套接字来连接的啊，连接前，服务器会有一个套接字进行监听的，当客户端发起连接时，就会产生已连接套接字，那个监听套接字会继续监听的...这样，套接字就对应了不同的连接。套接字是个文件类型。

主要特点：面向连接、面向字节流、全双工通信、通信可靠。优缺点：应用场景：要求通信数据可靠时，即 数据要准确无误地传递给对方。如：传输文件：HTTP、HTTPS、FTP等协议；传输邮件：POP、SMTP等协议ps：首部的前 20 个字节固定，后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节（最大60个字节）。TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。重要字段：客户端与服务器来回共发送三个TCP报文段来建立运输连接，三个TCP报文段分别为：（1）客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”；（2）服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”；（3）客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。ps：在建立TCP连接之前，客户端和服务器都处于关闭状态（CLOSED）,直到客户端主动打开连接，服务器才被动打开连接（处于监听状态 = LISTEN）,等待客户端的请求。TCP 协议是一个面向连接的、安全可靠的传输层协议，三次握手的机制是为了保证能建立一个安全可靠的连接。通过上述三次握手，双方确认自己与对方的发送与接收是正常的，就建立起一条TCP连接，即可传送应用层数据。ps：因 TCP提供的是全双工通信，故通信双方的应用进程在任何时候都能发送数据；三次握手期间，任何1次未收到对面的回复，则都会重发。为什么两次握手不行呢？结论：防止服务器接收了早已经失效的连接请求报文，服务器同意连接，从而一直等待客户端请求，最终导致形成死锁、浪费资源。ps：SYN洪泛攻击：（具体见下文）为什么不需要四次握手呢？SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。如何来解决半连接攻击？如何来解决全连接攻击？请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，客户端才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，服务器结束 TCP 连接的时间要早于客户端。TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。简言之，客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器才会发送 FIN 连接释放报文，对方确认后就完全关闭了TCP连接。举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。ps：设想这样一个情景：客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用TCP的保活计时器。基本原理：tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中，除开CLOSING。正常的三次握手包括4中状态变迁：服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁：正常的四次握手包含6种tcp状态变迁，如主动发起关闭方为客户端：客户端发送FIN进入FIN_WAIT1 -> 服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务器再发送FIN进入LAST_ACK状态 -> 客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务器收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务器的相关包，则进入CLOSED状态断开连接。CLOSING状态：连接断开期间，一般是客户端发送一个FIN，然后服务器回复一个ACK，然后服务器发送完数据后再回复一个FIN，当客户端和服务器同时接受到FIN时，客户端和服务器处于CLOSING状态，也就是此时双方都正在关闭同一个连接。在进入CLOSING状态后，只要收到了对方对自己发送的FIN的ACK，收到FIN的ACK确认就进入TIME_WAIT状态，因此，如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内，发出的FIN会很快被ACK从而进入到TIME_WAIT状态，CLOSING状态持续的时间就特别短，因此很难看到这种状态。我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。应用场景：UDP协议比TCP协议的效率更高，TCP协议比UDP协议更加安全可靠。下面主要对数据传输出现错误/无应答/堵塞/超时/重复等问题。注意：TCP丢包：TCP是基于不可靠的网路实现可靠传输，肯定会存在丢包问题。如果在通信过程中，发现缺少数据或者丢包，那边么最大的可能性是程序发送过程或者接受过程中出现问题。总结：为了满足TCP协议不丢包，即保证可靠传输，规定如下：注意：TCP丢包有三方面的原因，一是网络的传输质量不好，二是安全策略，三是服务器性能瓶颈先理解2个基础概念：发送窗口、接收窗口工作原理：注意点：关于滑动窗口的知识点：滑动窗口中的数据类型：ARQ解决的问题：出现差错时，让发送方重传差错数据：即 出错重传类型：流量控制和拥塞控制解决的问题：当接收方来不及接收收到的数据时，可通知发送方降低发送数据的效率：即 速度匹配流量控制：注意：拥塞控制：慢开始与拥塞避免：快重传和快恢复：补充：流量控制和拥塞控制的区别什么情况造成TCP粘包和拆包？解决TCP粘包和拆包的方法：传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。https://www.jianshu.com/p/65605622234bhttp://www.open-open.com/lib/view/open1517213611158.htmlhttps://blog.csdn.net/dangzhangjing97/article/details/81008836https://blog.csdn.net/qq_30108237/article/details/107057946https://www.jianshu.com/p/6c73a4585eba

1)URG：此标志表示TCP包的紧急指针域（后面马上就要说到）有效，用来保证TCP连接不被中断，并且督促中间层设备要尽快处理这些数据； (2)ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中；有两个取值：0和1，为1的时候表示应答域有效，反之为0；(3)PSH：这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序，而不是在缓冲区中排队；(4)RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包； (5)SYN：表示同步序号，用来建立连接。SYN标志位和ACK标志位搭配使用，当连接请求的时

确认（ACKNOWLEDGEMENT）、PUSH、复位标志RST、同步标志（syn）。 确认（ACKNOWLEDGEMENT）：确认标志用于确认数据包的成功接收。PUSH：在数据包到达接收端以后，立即传送给应用程序，而不是在缓冲区中排队。复位标志RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包。同步标志（syn）：该标志仅在三次握手建立TCP连接时有效。在三次握手期间，随着文件的交换和新连接的创建，可以看到更多的SYN标志被发送和接收。

通常，操作系统会将当前所有任务控制块组成一个双向的链表OSTCBList，这个链表将在函数OSTimeTick中被用到。 OSTimeTick函数是系统的时钟处理函数，他负责系统各任务的延时工作，一般情况下，OSTimeTick会被周期性的调用，其本质是操作上面所说的OSTCBList，它遍历链表中的每一个任务控制块的OSTCBDly字段，并将需要延时的任务的OSTCBDly值减1，当某人物的该字段值减为0时，这个任务就会在就绪表中被标记，任务结束等待进入就绪状态。 每个任务创建时，都会被加入链表OSTCBList中，在任务被删除时，相应控制块也会在链表中清除。 OS_STK *OSTCBStkPtr; //任务堆栈栈顶指针struct os_tcb *OSTCBNext; //指向后一个任务控制块stryct os_tcb *OSTCBPrev; //指向前一个任务控制块OSTCBEventPtr用来指向当前和任务密切相关的事件控制块，所谓密切相关，即任务阻塞在该事件上。在ucosII中，所有的任务同步与通信机制，包括信号量、邮箱、消息队列等都是通过事件控制块来描述，当任务请求同步或通信服务，并阻塞在相应事件上，OSTCBEventPtr字段就记录了这个事件对应的事件控制块. OS_EVENT *OSTCBEventPtr; //指向与任务当前事件相关的事件控制块OSTCBMsg字段在任务中使用邮箱或消息队列传输数据时被使用，该字段用于记录其他任务传递个本任务的数据的地址（即数据指针）。 void *OSTCBMsg; //用于指向从邮箱或队列中接收到的消息INT16U OSTCBDly; //用于任务等待延时，记录要等待的时钟滴答数。INT8U OSYCBStat; //任务当前状态任务状态对应值描述OS_STAT_RDY0x00任务就绪状态OS_STAT_SEM0x01任务等待信号量状态OS_STAT_MBOX0x02任务处于等待邮箱消息状态OS_STAT_Q0x04任务处于等待消息队列状态OS_STAT_SUSPEND0x08任务处于被挂起状态OS_STAT_MUTEX0x10任务处于等待互斥信号量状态OS_STAT_FLAG0x20任务处于等待事件标志组状态INT8U OSTCBPrio; //任务的优先级,值越小优先级越高。 //OS_CFG.H中的OS_MAX_TASKS定义最多用户使用控制块个数。这些任务控制块被放在OSTCBbl数组。 //以下四个字段与任务的优先级联系密切，用于加速任务的切换过程 INT8U OSTCBX; //该优先级在全局数组OSRdyTbl[]中对应的位置 INT8U OSTCBY; //该优先级在全局变量OSRdyGrp中对应位置 INT8U OSTCBBitX; //与OSTCBX值相对应的位掩码 INT8U OSTCBBitY; //与OSTCBY值相对应的位掩码 }OS_TCB;
源IP地址，源IP端口号，目的IP地址，目的IP端口号。