关关爱学习之面试一百问--TCP问题补充（与UDP区别、syn攻击、四种定时器）

学而时习之不亦说乎

1、描述TCP和UDP的区别？

TCP的优点： 可靠，稳定 TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。 TCP的缺点： 慢，效率低，占用系统资源高，易被攻击 TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。 而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。

UDP的优点： 快，比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击…… UDP的缺点： 不可靠，不稳定 因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。 基于上面的优缺点，那么： 什么时候应该使用TCP： 当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。 在日常生活中，常见使用TCP协议的应用如下： 浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输 ………… 什么时候应该使用UDP： 当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。 比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……
有些应用场景对可靠性要求不高会用到UDP，比如长视频，要求速率

TCp协议和udp协议的差别 ：
TCP UDP
是否连接 面向连接 面向非连接
传输可靠性 可靠 不可靠
应用场合 少量数据 传输大量数据
速度 慢 快

UDP应用场景：实时应用
1.面向数据报方式
2.网络数据大多为短消息
3.拥有大量Client
4.对数据安全性无特殊要求
5.网络负担非常重，但对响应速度要求高

具体编程时的区别
1.socket()的参数不同
　2.UDP Server不需要调用listen和accept
　3.UDP收发数据用sendto/recvfrom函数
　4.TCP：地址信息在connect/accept时确定
　5.UDP：在sendto/recvfrom函数中每次均 需指定地址信息
　6.UDP：shutdown函数无效

编程区别
通常我们在说到网络编程时默认是指TCP编程，即用前面提到的socket函数创建一个socket用于TCP通讯，函数参数我们通常填为SOCK_STREAM。即socket(PF_INET, SOCK_STREAM, 0)，这表示建立一个socket用于流式网络通讯。
　 SOCK_STREAM这种的特点是面向连接的，即每次收发数据之前必须通过connect建立连接，也是双向的，即任何一方都可以收发数据，协议本身提供了一些保障机制保证它是可靠的、有序的，即每个包按照发送的顺序到达接收方。

而SOCK_DGRAM这种是User Datagram Protocol协议的网络通讯，它是无连接的，不可靠的，因为通讯双方发送数据后不知道对方是否已经收到数据，是否正常收到数据。任何一方建立一个socket以后就可以用sendto发送数据，也可以用recvfrom接收数据。根本不关心对方是否存在，是否发送了数据。它的特点是通讯速度比较快。大家都知道TCP是要经过三次握手的，而UDP没有。

基于上述不同，UDP和TCP编程步骤也有些不同，如下：
TCP:
TCP编程的服务器端一般步骤是：
　　1、创建一个socket，用函数socket()；
　　2、设置socket属性，用函数setsockopt(); * 可选
　　3、绑定IP地址、端口等信息到socket上，用函数bind();
　　4、开启监听，用函数listen()；
　　5、接收客户端上来的连接，用函数accept()；
　　6、收发数据，用函数send()和recv()，或者read()和write();
　　7、关闭网络连接；
　　8、关闭监听；

TCP编程的客户端一般步骤是：
　　1、创建一个socket，用函数socket()；
　　2、设置socket属性，用函数setsockopt();* 可选
　　3、绑定IP地址、端口等信息到socket上，用函数bind();* 可选
　　4、设置要连接的对方的IP地址和端口等属性；
　　5、连接服务器，用函数connect()；
　　6、收发数据，用函数send()和recv()，或者read()和write();
　　7、关闭网络连接；

UDP:
与之对应的UDP编程步骤要简单许多，分别如下：
　　UDP编程的服务器端一般步骤是：
　　1、创建一个socket，用函数socket()；
　　2、设置socket属性，用函数setsockopt();* 可选
　　3、绑定IP地址、端口等信息到socket上，用函数bind();
　　4、循环接收数据，用函数recvfrom();
　　5、关闭网络连接；

UDP编程的客户端一般步骤是：
　　1、创建一个socket，用函数socket()；
　　2、设置socket属性，用函数setsockopt();* 可选
　　3、绑定IP地址、端口等信息到socket上，用函数bind();* 可选
　　4、设置对方的IP地址和端口等属性;
　　5、发送数据，用函数sendto();
　　6、关闭网络连接；

TCP和UDP是OSI模型中的运输层中的协议。TCP提供可靠的通信传输，而UDP则常被用于让广播和细节控制交给应用的通信传输。

UDP补充：
UDP不提供复杂的控制机制，利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立刻按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况下，UDP也无法进行流量控制等避免网络拥塞的行为。此外，传输途中如果出现了丢包，UDP也不负责重发。甚至当出现包的到达顺序乱掉时也没有纠正的功能。如果需要这些细节控制，那么不得不交给由采用UDP的应用程序去处理。换句话说，UDP将部分控制转移到应用程序去处理，自己却只提供作为传输层协议的最基本功能。UDP有点类似于用户说什么听什么的机制，但是需要用户充分考虑好上层协议类型并制作相应的应用程序。

TCP补充：
TCP充分实现了数据传输时各种控制功能，可以进行丢包的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在UDP中都没有。此外，TCP作为一种面向连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。

TCP与UDP区别总结：
1）udp是无连接的，即发送数据之前不需要建立连接，TCP是面向连接的传输层协议。

2）UDP使用尽最大努力交付，即不保证可靠交付。无需维持复杂的连接状态表。TCP提供可靠交付的服务。
TCP在数据传输过程中，采用了许多的方法和手段，如编号与确认、流量控制、计时器等，来保证在连接上提供可靠的传输服务，因此也增加了协议的开销。

3）UDP没有拥塞控制，因此网络拥塞不会使源主机的发送速率降低，允许拥塞造成丢失，不允许大时延。
UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

4）UDP是面向报文的。TCP面向字节流。
面向报文：发送方UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。接收方UDP对IP层上交的UDP用户数据包，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。

面向字节流：TCP协议把应用层报文看成是一连串无结构的字节流。将其分解为多个TCP报文段进行传输，在目的站再重新装配这些段，必要时需要重新发送没有收到的段。

5）udp支持一对一、一对多、多对一和多对多的交互通信。TCP连接只能有两个端点（endpoint），每一条TCP连接只能是点对点的（一对一）。

6）UDP首部固定8字节，开销小，处理时延小。TCP首部20字节固定。

7）TCP提供全双工的可靠信道，UDP是不可靠信道。

TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。

全双工通信，即通信的双方可以同时发送和接收信息的信息交互方式。

UDP是全双工吗？
所谓全双工，半双工，单工是指面向连接时才有的说法，如果不是面向连接的，没有一个确定的连接的话，怎么会出现半双工这种只准一个来或者一个去的说法呢？
UDP支持一对一，一对多，多对一和多对多的交互通信。如果一定要涉及到全双工的话，大概理解为不仅提供全双工，甚至提供全多工服务，只是UDP是不可靠的服务而已。

8）TCP有序，UDP无序：消息在传输过程中可能会乱序，后发送的消息可能会先到达，TCP头中有发送帧序号和期望接收的帧序号，收发双方通过滑动窗口协议保证收到下一个需要的帧时才提交给上层应用。

9）TCP要求系统资源较多，UDP要求较少。

-----------------------------------------------------关关爱学习------------------------------------------------

2、TCP的syn攻击的过程？追问：怎么防御？

SYN攻击的原理：在等待一个ACK的时候，系统会建立一个等待缓存，客户端发送大量的SYN，但客户端却不回复ACK，缓存很快被占满，那么正常的主机就没有地方去等，只能丢弃。

防御手段：
1）可以对SYN包进行监视，如果发现某个IP发送了大量SYN即将该IP列入黑名单。

2）因为消耗服务器资源主要是因为当SYN数据报文一到达，系统立即分配TCB，从而占用了资源。而SYN Flood由于很难建立起正常连接，因此，当正常连接建立起来后再分配TCB则可以有效地减轻服务器资源的消耗。常见的方法是使用Syn Cache和Syn Cookie技术。

Syn Cache技术：
这种技术是在收到SYN数据报文时不急于去分配TCB，而是先回应一个SYN ACK报文，并在一个专用HASH表（Cache）中保存这种半开连接信息，直到收到正确的回应ACK报文再分配TCB。在FreeBSD系统中这种Cache每个半开连接只需使用160字节，远小于TCB所需的736个字节。在发送的SYN ACK中需要使用一个己方的Sequence Number，这个数字不能被对方猜到，否则对于某些稍微智能一点的Syn Flood攻击软件来说，它们在发送Syn报文后会发送一个ACK报文，如果己方的Sequence Number被对方猜测到，则会被其建立起真正的连接。因此一般采用一些加密算法生成难于预测的Sequence Number。

Syn Cookie技术：
对于SYN攻击，Syn Cache虽然不分配TCB，但是为了判断后续对方发来的ACK报文中的Sequence Number的正确性，还是需要使用一些空间去保存己方生成的Sequence Number等信息，也造成了一些资源的浪费。
Syn Cookie技术则完全不使用任何存储资源，这种方法比较巧妙，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源。

3）防火墙，Syn Cache技术和Syn Cookie技术总的来说是一种主机保护技术，需要系统的TCP/IP协议栈的支持，而目前并非所有的操作系统支持这些技术。因此很多防火墙中都提供一种SYN代理的功能，其主要原理是对试图穿越的SYN请求进行验证后才放行，防火墙在确认了连接的有效性后，才向内部的服务器（Listener）发起SYN请求，所有的无效连接均无法到达内部的服务器。而防火墙采用的验证连接有效性的方法则可以是Syn Cookie或Syn Flood等其他技术。

-----------------------------------------------------关关爱学习------------------------------------------------

3、TCP有哪些定时器？

在TCP协议中有的时候需要定期或者按照某个算法对某个事件进行触发，那么这个时候，TCP协议是使用定时器进行实现的。在TCP中，会有四种定时器：

(1)重传定时器
(2)坚持定时器
(3)保活定时器
(4) 时间等待计时器

这四个定时器都有各自的具体作用。

1）重传定时器

重传定时器：为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间。当TCP发送报文段时，就创建这个特定报文段的重传计时器，可能发生两种情况：若在计时器超时之前收到对报文段的确认，则撤销计时器；若在收到对特定报文段的确认之前计时器超时，则重传该报文，并把计时器复位；

重传时间=2*RTT；

RTT的值应该动态计算。常用的公式是：RTT=previous RTT*i + （1-i）*current RTT。i的值通常取90%，即新的RTT是以前的RTT值的90%加上当前RTT值的10%.
Karn算法：对重传报文，在计算新的RTT时，不考虑重传报文的RTT。因为无法推理出：发送端所收到的确认是对上一次报文段的确认还是对重传报文段的确认。干脆不计入。

2）坚持定时器

坚持定时器是使用在一方滑动窗口为0之后，另外一方停止传输数据，进入坚持定时器的轮询，直到滑动窗口不再为0了。

说说术语，首先是滑动窗口，可以简单理解为缓冲区剩余空间大小。不管是写缓冲还是读缓冲，一旦一方通告了自己的滑动窗口大小，另外一方就会根据滑动窗口大小传递窗口大小的数据了。但是，当被通告，一方的滑动窗口大小为0的时候，另外一方就会启动坚持定时器，基本也是使用TCP指数退避方法，第一次1.5秒，第二次1.5x2秒，第三次1.5x4…

其次是糊涂窗口综合症。这个症状是滑动窗口引起的。病因是发送方和接收方在一个很小的滑动窗口的时候就开始数据传输，传输结束之后，读写的消费速度也并没有那么快，导致下次传输的时候，滑动窗口还是那么小。然后现象就是每次传输的数据都非常小。就好比每次开出去的火车载货量只有一节车厢，其实我们是希望能攒够n节车厢才开始传输。

糊涂窗口综合症有解决办法，还不止一种，在接收方或者发送方都可以解决。大致就是如果接收方解决，那么接收方在接收窗口小于一定大小的时候，对所有的接收请求都返回窗口为0的包，来触发另外一方的坚持定时器。同样发送方也是，在可以发送的数据大于一定窗口的时候才发送。

3）保活定时器

这个就是我们经常说的tcp的keepalive了。实际使用场景是在应用层没有数据进行传输的时候，一定时间（tcp_keepalive_time，默认每2个小时）发送一次保持心跳的包，如果发送成功，则继续保持端口活跃，如果没有正常返回，则在指定次数内（tcp_keepalive_probes，默认是9次），指定间隔（tcp_keepalive_intvl，默认是17s）发送心跳包。如果最后都没有获得正常的ACK，那么才算连接失败。

当然，tcp是否需要提供keepalive机制，是有争议的，我们可以为每个tcp连接设置是否启用keepalive和启用keepalive的各个指标设置。

4）时间等待定时器

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

补充：
2MSL定时器：MSL是报文段做大生存时间(Maximum Segment Lifetime),设置这个定时器有两个目的：

其一是为了测量连接处于TIME_WAIT状态的时间.这样可以让TCP再次发送最后的ACK以防止这个ACK丢失(如果丢失，另一端会重传FIN)。

其二，为允许老的重复分节在网络中消逝。具体可以解释为，如果一个TCP连接在断开之前有迷途分节尚未消逝，在断开该TCP连接之后立刻重启一个同样的连接(双方的IP地址和端口port相同)，这时之前的迷途的老分节可能对新的新的TCP连接接收，从而造成未定义的错误。为了避免这种情况，TCP规定在TIME_WAIT状态，不能启动一个连接的化身。既然TIME_WAIT状态维持2MSL，这就保证了一个连接上的分组及其应该在 2MSL内都会消失。