面向连接:使用TCP协议通信的双方必须先建立连接,然后才能开始数据的读写。双方都必须为该连接分配必要的内核资源,以管理连接的状态和连接上数据的传输。TCP连接是全双工的,即双方的数据读写可以通过一个连接进行,完成数据交换不再使用该连接之后,通信双方都必须断开连接,以释放资源。并且TCP协议的这种连接是一对一的,所以基于广播和多播(目标是多个主机)的应用程序不能使用TCP服务。而无连接的UDP协议则非常适用于广播和多播。
字节流:被发送的TCP报文先被放入TCP发送缓冲区,在真正发送时,在缓冲区内的数据被封装成一个或多个TCP报文,接收端也是如此,所以TCP发送端的写操作次数和接收端的读操作次数是没有数量关系的,也就是说应用程序对数据的发送和接收是没有边界限制的。
可靠传输:首先是,TCP协议采用发送应答机制,即发送端发送的每个TCP报文段都必须得到接收方的应答,才认为TCP报文段传输成功。其次,TCP协议采用超时重传机制,发送端在发送出一个TCP报文段之后启动定时器,如果在定时时间内未收到应答,它将重发该报文段。最后,因为TCP报文段最终是以IP数据报发送的,而IP数据报达到接收端可能乱序、重复,所以TCP协议还会对收到的TCP报文进行重排、整理,再交付给应用层。
这是因为服务端在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。而关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方也未必全部数据都发送给对方了,所以己方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送。
在三次握手过程中,服务器发送在SYN-ACK之后,收到客户端的ACK之前的TCP连接称为半连接(half-open connect),此时Server处于SYN_RCVD状态,当收到ACK后,Server转入ESTABLISHED状态。
SYN攻击就是客户端在短时间内伪造大量不存在的IP地址,并向服务器不断地发送SYN包,服务器回复确认包,并为该请求分配一个任务控制块TCB(Transmission Control Block),然后等待客户端的确认,由于源地址是不存在的(或者源地址不知晓),因此,服务器需要不断重发直至超时,这些伪造的SYN包将长时间占用未连接队列和服务器资源,导致正常的SYN请求因为队列满而被丢弃,从而引起网络堵塞甚至系统瘫痪。
这里关于未连接队列的问题:TCP连接三次握手中的重要数据结构:半连接队列和全连接队列
比较蠢的办法:增大队列SYN最大半连接数、减小超时值
1.延时分配TCB 。当正常连接建立起来后再分配TCB则可以有效地减轻服务器资源的消耗。
常见的方法是使用SYN Cache和SYN Cookie技术。
2.使用SYN Proxy防火墙。防火墙中都提供一种 SYN代理的功能,其主要原理是对试图穿越的SYN请求进行验证后才放行。
校验和
确认应答和序列号
超时重传
连接管理
流量控制
拥塞控制
上图中共有四个部分:已经发送并收到确认的数据、 发送了但是还没收到确认的数据、在当前窗口大小范围内还能再发送的数据、超出窗口范围的未发送数据。
滑动窗口作用:(1)滑动窗口允许发送方连续发送多个报文(2)根据对方接收窗口大小限制发送方的发送速率,防止拥塞
滑动机制:
1.发送窗口只有收到发送窗口内字节的ACK确认,才会移动发送窗口的左边界。
2.接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下,窗口不会移动,并不对后续字节确认。以此确保对端会对这些数据重传。
3.遵循快速重传、累计确认、选择确认等规则
4.发送方发的window size = 8192;就是接收端最多接收8192字节,这个8192一般就是接收方接收缓存的大小
对比滑动窗口和拥塞窗口比较:
滑动窗口是控制接收以及同步数据范围的,通知发送端目前接收的数据范围,用于流量控制,接收端使用。拥塞窗口是控制发送速率的,避免发的过多,发送端使用。因为TCP是全双工,所以两边都有滑动窗口。
两个窗口的维护是独立的,滑动窗口主要由接收方反馈缓存情况来维护,拥塞窗口主要由发送方的拥塞控制算法检测出的网络拥塞程度来决定的。
连接机制:
TCP 是面向连接的传输层协议,需要占用内核资源多
UDP 是不需要连接的,资源占用少
服务对象:
TCP 是一对一的两点服务
UDP 支持一对一、一对多、多对多
可靠性:
TCP 保证数据不丢失、不重复、按需到达
UDP 是尽最大努力交付,不保证交付数据
速度:
UDP速度快于TCP
数据流:
TCP是字节流,没有边界限制
UDP是数据报流,需要以个体为单位发送和读取
拥塞控制、流量控制:
TCP 有拥塞控制和流量控制机制
UDP 则没有拥塞控制和流量控制机制
TCP可靠稳定,可以使得整个数据准确无误的传递给对方,这往往用于一些要求可靠的应用,比如HTTP、HTTPS、FTP等文件传输协议,POP、SMTP等邮件传输的协议。
要求网络通讯速度能尽量的快,这时就可以使用UDP。实时语音视频通话、实时游戏、TFTP等。
三次握手:
四次挥手:
定义一个时间段,在这个时间段内,如果没有任何连接相关的活动,TCP保活机制会开始作用,每隔一个时间间隔,发送一个探测报文,该探测报文包含的数据非常少,如果连续几个探测报文都没有得到响应,则认为当前的TCP 连接已经死亡,系统内核将错误信息通知给上层应用程序。
TCP的保活机制详解
如果发送数据,要看套接字是否响应?
如果客户端和服务器没有进行数据传输的话,会触发TCP的保活机制。TCP保活机制对应的参数包括保活时间、保活探测的次数、保活探测的时间间隔,其中保活时间默认为7200秒,保活探测次数为9,保活探测时间间隔为75秒。也就意味着,如果客户端突然故障,会经过7200+75*9=7875秒即2小时11分15后,服务器才会判断该连接失效,以上参数可以手动设置。
Nagle算法:
Nagle算法要求一个TCP连接的通信双方在任意时刻都最多只能发送一个未被确认的TCP报文段,在该报文段的确认到达之前不能发送其他TCP报文段。另一方面,发送方在等待确认的同时收集本端需要发送的微量数据,并在确认到来时以一个TCP报文段将它们全部发出。这样就极大地减少了网络上的微小TCP报文段的数量。
该算法还有一个优点是其自适应性:确认到达的越快,数据也就发送的越快。
延时确认机制:
服务器不会马上确认上次收到的数据,而是延迟一段时间后查看本端是否有数据需要发送,再和确认信息一起发送。这样可以避免大量的ACK以一个单独的TCP包发送,减少了网络流量。
在局域网内,因为服务器对客户请求处理的很快,所以服务器发送确认报文段的时候总是有数据一起,延时确认可以减少发送TCP报文段的数量。而因为用户输入速度明显慢于客户端程序的处理速度,所以客户端的确认报文段总是不携带任何应用程序数据。