TCP、UDP整理

TCP协议

  1. TCP协议是什么？

    答：TCP（Transmission Control Protocol）传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。

  2. TCP的特性有哪些？

    答：

    • 对数据执行分割和重组：每次传输都会对数据包负载有大小限制，应用层将数据统统发给TCP协议，TCP将数据进行合理分割，在接收端将数据进行合理重组；
    • 确保数据按顺序传输 ：发送端的TCP协议会为自己发出的数据标明序列号（seq），在接收端TCP协议对数据进行重新排序，确保了数据的有序传输；
    • 同时为多个应用程序提供传输服务
    • 确认接收方收到数据并按需传输：在接收方接收到数据后一定要向发送方进行确认，如果发送方没有收到接收方的确认，就会把未确认的数据进行重发
    • 控制传输速率：通过滑动窗口来实现

  3. TCP头部长度字段可标记的最小长度为20个字节（固定头部），最大长度为60个字节

  4. TCP三次握手？

    答：

    • 第一次握手：客户端向服务器发送一个SYN报文,发起建立连接请求

      • 在客户端发送的数据段中，控制字段SYN置1代表这是一个连接建立请求，序列号为客户端随机生成的数值，假设seq=a，确认号为0；发送完这个SYN报文后，客户端处于SYN_SEND状态；此时不携带数据

    • 第二次握手：服务器接收到建立连接请求后，向客户端返回一个标识了SYN和ACK的数据段

      • 在服务端发送的数据段中，控制字段SYN和ACK置一，序列号为服务器随机生成的数值，假设seq=b，确认号此时为a+1；发送完SYN+ACK报文后，服务器处于SYN_RECV状态

    • 第三次握手：客户端向服务器发送ACK数据段进行响应

      • 在客户端发送的数据段中，控制字段ACK置一，序列号为a+1，确认号为b+1，确认客户端收到了服务器发来的序列号为b的数据段；此时ACK数据段可以携带数据，客户端处于ESTABLISHED状态，服务器收到报文后也处于ESTABLISHED状态，双方建立连接成功

  5. TCP四次挥手？

    答：

    • 第一次挥手：客户端向服务器发送一个FIN和ACK的数据段，发起断开连接请求
      • 客户端主动关闭连接，控制字段FIN和ACK置一;客户端进入FIN_WAIT1状态；假设seq=a，确认号为0
    • 第二次挥手：服务器在接收到数据段后，以seq=b,ack=a+1的数据段进行响应
      • 服务器处于CLOSE_WAIT状态；客户端收到服务器的确认报文后，处于FIN_WAIT2状态
    • 第三次挥手：由于TCP是双向连接，需要通信双方都拆除连接，因此服务器也会向客户端发送标识了FIN和ACK的数据段，假设序列号为c
      • 服务器处于LAST_WAIT状态
    • 第四次挥手：客户端在接收到数据段后，以序列号为a+1，确认号为c+1的数据段进行响应，至此，客户端和服务器的TCP连接断开
      • 客户端处于TIME_WAIT状态，等待2MSL，服务器和客户端处于CLOSED状态

  6. 为什么是三次握手而不是两次握手？

    答：

    • 确保客户端和服务端都拥有正常的收发能力；
      • 第一次握手，验证了客户端具有正常的发送数据的能力；第二次握手，验证了服务器具有正常的数据收发能力；第三次握手的存在就是服务器为了确认客户端具有正常的接收数据的能力
    • 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误（自己的理解，还是为了保证TCP连接的可靠性）

  7. TCP短连接和长连接的优缺点？

    答：

    • TCP 短连接：短连接建立和断开连接简单；但是客户端频繁的请求连接，也会占用时间、宽带，造成资源的浪费。对于网站服务器，一般都采用短连接
    • TCP 长连接：对于频繁的请求操作，比如数据库的操作保持长连接，可以减少资源的浪费；但是如果一直保持连接，有大量的客户端都保持长连接，最终会造成服务器压力过大。

  8. 半连接队列是什么？

    答：服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RECV 状态，此时双方还没有完全建立连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

  9. 在三次握手时，服务器发送完SYN-ACK包后，如果长时间未收到客户端的确认包，怎么处理？

    答：如果未收到客户端的确认包，服务器会进行首次重传，等待一段时间后如果仍未收到客户端确认报，则会进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将会从半连接队列删除此次连接。

  10. 在三次握手时，可以携带数据吗？

    答：第一次、第二次握手不可以携带数据，第三次握手可以携带数据。

    • 为了避免服务器受到SYN攻击，第一次握手不携带数据。

  11. SYN攻击是什么？怎么防范SYN攻击？怎么检测SYN攻击？

    答：

    • SYN 攻击是客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送SYN包，服务器回复确认包，并等待客户端的确认。由于源地址不存在，所以服务器会不断重发直至超时，这些伪造的SYN包会长时间占用半连接队列，导致正常的SYN请求被丢弃，造成服务器资源浪费，引起网络堵塞甚至系统瘫痪。总结：SYN攻击是DDoS攻击的一种，利用TCP协议缺陷，通过发送大量的半连接请求，耗费CPU和内存资源。
    • 防范SYN攻击
      • 通过防火墙、路由器等过滤网关防护
      • 降低SYN timeout时间，使服务器尽快释放半连接
      • 采用SYN cookie设置，如果短时间受到某IP的重复SYN请求，即认为受到SYN攻击
      • 增加最大半连接数
    • 检测SYN攻击：当在服务器上看到大量的半连接状态且源IP地址是随机的，基本上就可以断定是SYN攻击。

  12. 为什么建立连接是三次握手，关闭连接是四次握手？

    答：

    • 建立连接时，当服务器收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文，SYN报文用来同步建立连接，ACK报文用于请求应答
    • 关闭连接时，如果客户端数据发送完毕后，会给服务器先发送一个FIN报文。当服务器收到FIN报文后，先发送ACK应答，首先关闭客户端到服务器的数据发送。由于TCP是全双工的，每个方向都要进行关闭。当服务器数据发送完毕后，会给客户端发送FIN报文，所以发送ACK应答和FIN报文要经过两次挥手，确保数据发送的完整性。

  13. TCP第四次挥手为什么要等待2MSL?

    答：MSL(Maximum Segment Lifetime)“报文最大生存时间”，是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

    TCP 第四次挥手要等待 2MSL，主要有两个原因：

    • 为了保证客户端发送的最后一个 ACK 报文段能够到达服务器。如果ACK 丢失会导致处在 LAST-ACK 状态的服务器收不到对 FIN-ACK 的确认报文。服务器会超时重传这个 FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待 2MSL，而是在发送完 ACK 之后直接释放关闭，一旦这个 ACK 丢失的话，服务器就无法正常的进入关闭连接状态。
    • 可以防止已失效的报文段出现在新的连接中。客户端在发送最后一个 ACK 之后，再经过2MSL，就可以使本连接持续时间内所产生的所有报文段都从网络中消失，保证在关闭连接后不会有滞留的报文段影响新的连接。

  14. 流量控制的理解？
    答：流量控制是对端到端通信量的控制，抑制发送端发送数据的速率使接收端方便接收。

    【为了避免发送方数据发送的过快，接收方来不及接收时造成数据丢失】

  15. 流量控制机制？

    答：

    • 利用滑动窗口机制可以实现对发送方的流量控制
    • 通过协议字段中的窗口大小（不会大于接收方的接收缓冲区中剩余空间的大小）字段控制发送方发送的数据大小，避免因为发送过快而接受方数据处理过慢导致接收缓冲区数据放满后，大量的数据丢失重传降低性能；窗口大小在每次对数据进行确认回复的时候都会进行重新协商

  16. 拥塞控制的理解？

    答：拥塞控制是防止过多的数据注入到网络中。

  17. 拥塞控制机制？

    答：慢开始、拥塞避免、快重传、快恢复

    • 网络通信开始时，并不会直接发送窗口大小的数据，而是以一种慢启动，快增长的形式进行数据传输，起到一个网络探测的作用，避免开始通信时因为网络不好导致的发送数据越多，丢失数据越多的重传性能损失，在快增长的过程中，若出现丢包则初始化拥塞窗口大小，重新开始探测网络状况；
    • 快重传： 接收方收到了第二条数据，但是没有收到第一条，则初步认为第一条数据丢失，则立即发送第一条数据的重传请求，并且连续发送三次（连续三次是避免因为网络阻塞、数据延迟到达而导致的重传）

  18. 延迟应答机制？捎带应答机制？保活机制？

    答：

    • 接收方接收数据若是立即回复，则窗口大小会减小，会导致传输速度降低，因此接收方接收到数据之后，并不会立即回复，而会延迟一会（不超过500毫秒），在这期间，用户能将数据从接收缓冲区中取出，可以尽量大的能力保证窗口大小，保证传输速度不会降低
    • 每次接收方对发送的数据进行确认回复，若是单独发送一个数据段（仅仅包含一个tcp报头）是不划算的，解决方案就是将要进行的确认回复和将要发送的数据合到一起进行发送，就可省略一个tcp报头的发送，减少网络中不必要的流量信息
    • 若是通信双方长时间没有数据往来（7200秒，即两小时），则会向对方发一个保活探测数据包，要求对方对这个数据包进行回复，若是收到回复，则连接正常，若是连续多次（9次，每次间隔75秒）没有收到回复，则认为连接断开（在Linux下输入：sysctl -a |grep keep 命令可以查看）

  19. 面向字节流？

    答：数据不会直接发送，而是放在缓冲区中，操作系统选择一个合适的时机将合适大小的数据以字节流的形式发送出去，对方接收数据时可以一次性接收所有数据，也可以一次接受一点，分多次接受

  20. 粘包问题是什么？发生的原因？解决方法？

    答：

    • 传输的数据在发送缓冲区或者接受缓冲区中堆积，因为tcp数据收发的灵活性，导致有可能多条数据当作一条接收；（两条数据的粘连）
    • 粘包的本质原因：tcp在传输层，对数据的格式并不关心，对数据之间没有边界区分，因此会造成数据粘包；
    • 解决粘包问题的方法
      • 使用特殊字符间隔
      • 定长数据
      • 在协议头中声明数据长度

UDP协议

  1. UDP协议是什么？

    答：UDP（User Datagram Protocol）协议称为用户数据报协议。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据报的方法。

    【无连接、不可靠、面向数据报】

  2. UDP首部8个字节

  3. TCP和UDP的区别是什么？

    答：

    • TCP 面向连接的，而 UDP 无连接
    • TCP 是可靠传输，具有超时重传、数据应答等机制，UDP 是不可靠传输，尽最大能力去交付
    • TCP 是点对点连接，UDP 可以一对一、一对多、多对多连接
    • TCP 面向字节流，UDP 面向数据报
    • TCP强调可靠性，允许少量延迟；UDP强调高效性，允许部分丢包
    • TCP 给 HTTP、HTTPS、FTP、TELNET、SMTP 等使用，UDP 给 DNS、DHCP、TFTP 等使用
posted @ 2020-07-13 21:33  guguda  阅读(135)  评论(0)    收藏  举报