tcp面向连接管理--传输层协议

适用场景:数据安全性高
如何调用接口:
服务端:创建套接字–>绑定地址信息–>开始监听–>获取已近完成连接–>收发数据–>关闭套接字
客户端:创建套接字–>绑定地址信息(系统绑定)—>向服务器发送连接请求–>收发数据–>关闭套接字
1创建套接字
sokcet
参数1)AF_INET(IPV4)2)SOCK_STREAM(TCP)
3)6/IPPROTO
2bind绑定
1套接字描述符2端口号3地址域信息4长度
返回值成功0,失败-1
3listen监听
参数 :
1套接字描述符2最大并发连接数–同一时间最大连接数
成功0,失败-1
4accept
套接字描述符 addr:新连接客户端的地址信息addrlen:地址信息长度(输入输出复合参数),
成功新建立socket的描述符失败-1
5服务端收发数据recv
1:套接字描述符2:接收的数据放到哪一块len接受数据长度flag默认给0阻塞接收
flag参数有MSG_PEEK–>探测性接收(数据符合要求则接受不符合则不接受)
返回值:返回实际的接收长度 失败:-1
6send收发数据
参数1socket描述符,buf中的数据,长度为len;flags默认给0阻塞操作slen表示当前已经发送的数据的长度开始发送–>buf+slen发送,发送长度为len-slen
返回值成功实际的发送长度失败:-1–>实际完成操作是将数据拷贝到缓冲区里-- >会被打断->进程终止,信号,–>万一被打断就继续发
7客户端发起连接请求connect
1:客户端socket描述符2:服务端的地址信息(通过socket向服务端发起连接请求)参数3:地址信息的长度
返回值0 -1
tcp如何实现面向连接管理
1tcp协议格式:

(1)第一层0-15源端口16-31目的端口
(2)第二层32位序号
2)第3层32位确认序号
(4)4位首部长度+保留6位+6位标志为–16-31-16位窗口大小
6位标志(1)紧急指针是否有效(2)ack确认号是否有效(3)psh提示接收端应用程序重tcp缓冲区把数据拿走rst对方要求重新建立连接把带有rst标识的称为复位报文段syn请求建立连接,带syn标识的称为同步报文段fin通知对方本端要关闭了携带fin标识的为结束报文段
4位TCP报头长度: 表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60
(5)16位校验和+16位紧急指针
发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 包含TCP数据部分.
16位紧急指针: 标识哪部分数据是紧急数据;

tcp建立连接的过程(三次握手)
(1)服务端处于listen状态客户端处于LISTNE状态就可以接受客户端请求
客户端SYN_SENT -->SYN–>新建socket(new socket)调用connect向服务器发起连接请求(connect会发送段并阻塞等待服务器应答)—第一次
(2)服务端收到客户端的syn会应答,处于SYN_RCV:发送ACK+SYN(同意建立连接)–第二次
(3)客户端收到syn+ack后会客户端进入ESTABLISHED 从connect返回同时应答一个ack(第三次)服务端进入ESTABLISHED
tcp建立连接的过程(四次挥手)
(1)客户端close -->FIN进入FIN_WAIT_1 , 客户端会向服务器发送FIN段(第一次);
(2)服务器收到FIN后, 会回发ACK,进入close_wait 同时read会返回0 (第二次)客户端收到ack包后进入fin_wait2
(3read返回后(read返回0就表明收到了fin), 服务器知道客户端关闭了连接, 调用close关闭连接,服务器会向客户端发送一个FIN也就是调用当colse准备关闭连接 会先发送–>FIN此时服务端进入LAST_ACK,
(4)客户端收到FIN(进入time_wait), 再返回一个ACK给服务器; (第四次),在等了2MSL时间客户端colsed
tcp遇到的问题
1为什么握手3次挥手4次
两次不可靠四次没有必要,两次:SYN有可能是网络延迟后的包如果直接建立连接客户端已经下线,避免网络当中的延迟SYN和Ack只是个标志位,全部置1
为什么4次挥手:发送了很多请求,fin和ack放在一起有可能发送的数据没有取完(没有将ACK和fin合在一起)
2三次握手第三次失败怎么办
若第三次握手失败服务端如何处理?给客户端发送一个st_reset(重置连接请求)
3time_wait状态的作用
最后一个ack丢失,被动关闭方重发FIN包,没有等待直接关闭若直接启动的客户端有使用相同端口信息有可能受到FIN(状态不对会重新发送一个ack),对新连接造成影响若新启动客户端使用相同端口信息,向服务端发送SYN请求,但是服务端因为没有收到最后一个ACK处于LAST_ACK状态,收到SYN后判断状态错误,回复RST报文重置连接也对新连接造成影响.因此主动关闭方发送最后一个ack之后需要等待一段时间:(两个MSL时间)
4出现了大量time_wait连接出现原因如何解决
服务端有大量的短连接关闭–>参数设置把时间调短一点
程序因为TIME_WAIT 状态无法快速重启程序(绑定端口失败)解决方法setsocket启动地址复用
5syn泛洪攻击
SYN- Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它就是利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量 的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现，但至今仍然显示 出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。它的数据包特征通常 是，源发送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回复。
原理：攻击者首先伪造地址对 服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务 器没有收到回应，这样的话，服务器不知 道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者 如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。
解决方法
． 无效连接监视释放
这种方法不停的监视系统中半开连接和不活动连接，当达到一定阈值时拆除这些连接，释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉，”伤敌一千，自损八百“
延缓TCB分配方法
SYN Flood关键是利用了，SYN数据报文一到，系统立即分配TCB资源，从而占用了系统资源，因此有俩种技术来解决这一问题
Syn Cache技术
这种技术在收到SYN时不急着去分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中（Cache）中保存这种半开连接，直到收到正确的ACK报文再去分配TCB
Syn Cookie技术
Syn Cookie技术则完全不使用任何存储资源，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方 的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源
使用SYN Proxy防火墙
原理：对试图穿越的SYN请求进行验证之后才放行
6tcp的断开
tcp协议栈有自身的保活机制长时间无数据通信则发送保活探测包进行连接探测如果多个探测包没有响应则认为断开
断开的体现recv返回0/send触发SIGPIPE异常
TCP如何实现可靠传输
1确认应答机制,(每发送一个数据就回复一个ACK)
2超时重传机制(半天没有收到确认应答数据可能丢了或者收到数据了但是ACK丢了),过了时间重新穿送一次
通过这两个可以保证数据安全到达–>但是无法保证数据有序到达
3.3.32位序号,和32位确认序号对每个数据进行了排序保证有序到达缺点性能低ack丢了得重传
通信前先协商,数据序号从哪里开始(长度多少)(seq=1,len=1024),对方收到接受到后,下一个请求的是(ack=1025),则在发送数据是(seq=1025,len=1024)—>ack(2049)如果从1025开始则前面1024个空着直到来为止所以tcp可以保证包序
几种机制来避免大量的丢包重传以及ack丢失重传来保证性能
(1)滑动窗口机制
通过协议字段中的窗口大小双方进行协商,一次最多传输多少数据,之后等待确认应答,不需要一一停等,
发送数据窗口:1(后沿)–4096(前沿),还有个指针表示发送到哪里了知道走到4096然后一次性发送完了,后沿数据没有收到ACK应答,后沿不会移动直到收到才会移动这个指针,刚开始发送1024接受数据(接收窗口)1–4086 窗口一定比缓冲区小,通过窗口实现流量控制,对方收到1024则回复ACK=1025此时接收窗口变成3072,发送窗口收到ACK,1号收到了收到了1025表示前面已经收发成功,则后面已经走到1025,然后窗口大小变成3072,发送数据但使接收数据窗口有可能会接收到1025-2048会乱序,服务端回复1025 2049 3073 4097 如果客户端收到了2049就表示1025和2049成功如果数据丢失 只收到了第二条表示第一条丢失了–>然后服务端会发送三次请求,才能知道1024丢失了三次请求时间小于超时等待时间
(1.1)滑动窗口的作用:协商窗口大小进行流量控制,避免缓冲区数据塞满造成大量丢包重传
(1.2)滑动窗口中的快速重传
每条数据的确认回复都必须按序回复,若前面数据没有收到则不会对后面的数据进行回复(乱序情况);
1.意味着如果接收到了一条回复,表示ACK确认序号之前的数据全部安全到达,则不会因为前面数据的ACK丢失而重传数据
2.若前边数据丢失,则接收方收到后发的数据,则接收方理解发送重传请求,并且连续发送三次,若发送方连续收到三次重传请求,则认为数据丢失,进行重传
(1.3)滑动窗口中的拥塞控制:慢启动,快增长,
拥塞控制:发送端控制一个拥塞窗口大小,在进行数据传输的时候,进行网络探测式的发送,如果网络状况良好,则发送的数据快速增长,达到阈值(窗口大小)时,则不再继续增长,若传输过程中出现丢包,则重新初始化拥塞窗口,拥塞控制为了避免因为网络状况不好导致通信初始,大量的数据包丢失重传,降低性能拥塞窗口是发送端维护的
(2)延迟应答机制
接收方收到数据后并不立即进行确认回复,而是等待一段时间因为这段延时的时间内有可能用户已经recv将缓冲区将数据取走,窗口就可以尽可能的保证最大大小保证传输吞吐量
(3)捎带应答机制
接收方对每一条数据的确认回复,都需要发送一个tcp数据报;但是空报头的传输会降低性能;因此会考虑在即将要发送的数据报头中包含有确认信息,(可以少发一个确认的空报头)
面向字节流(管道)传输灵活,存在粘包问题:
粘包问题要发生的位置:发送缓冲区数据堆积和接收缓冲区的数据堆积–>没有及时recv本质数据没有明显的格式约定,tcp只管传输数据的字节流导致发送端/接收端因为数据的堆积在实际发送或recv时一次获取到半条或多条数据
如何解决:tcp在传输层没有数据边界,但是用户可以在应用层进行边界处理
常见方法:特殊字符间隔(http),定长数据(udp头中包含长度)!!
tcp应用:提供全双工的通信服务; 所谓全双工的意思是, 在同一条连接中, 同一时刻, 通信双方
可以同时写数据;
适用场景:数据安全性高