【Linux】TCP/UDP/HTTP面试问题

本文深入解析TCP和UDP两种网络协议的特性与区别,探讨SYN泛洪攻击原理及防范措施,详细阐述TCP、UDP报头结构,解释三次握手与四次挥手过程,对比HTTP与HTTPS的差异。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1、UDP和TCP的区别

  • TCP
  • 有连接
  • 可靠的传输
  • TCP是点对点的两点间服务,即一条TCP连接只能有两个端点:
  • TCP有流量控制拥塞控制保证数据传输的安全性
  • TCP报文长度是用接收方的窗口大小和当前的网络状况决定的
  • TCP首部开销大,需要20个字节
  • UDP
  • 无连接
  • 不可靠
  • UDP支持1对1,1对多,多对多
  • UDP没有拥塞控制,网络阻塞不会影响发送效率
  • UDP是面向报文的,保留从上面传下来的报文边界
  • UDP首部开销小,要8个字节(源端口,目的端口,数据长度,校验和)
  • 适用于场景
  • 若通讯数据的完整性要让位于数据的实时性时,就应该使用TCP,例如重要文件的传输
  • 若实时性更加重要时,则使用UDP,(如视频通讯,语音通话)
  • UDP丢包问题延伸

2、SYN泛洪攻击的出现和防治

出现:

在这里插入图片描述

  • 假如在这“握手”的过程中,客户端程序因为莫名崩溃等原因,收到SYN+ACK报文后不再回以ACK,服务端将如何处置,这时服务端会“优雅地”再等等,会不会是发送的包丢失了呢?
  • 于是重新发送一遍SYN+ACK,再收不到来自客户端的ACK响应的话,就把这次连接丢弃掉。这个过程大约会“优雅地”持续分钟级,这个持续时间被称作SYN timeout时间。大量的握手请求涌向TCP服务端,而它们只发出SYN报文而不以ACK响应结束握手,服务端就要为这每一个请求都维持约一分多钟的连接去等待ACK,也就形成所谓的“半连接”。维护这些半连接是需要消耗很多服务器的网络连接资源的。如果短时间内这些资源几乎都被半连接占满,那么正常的业务请求在这期间就得不到服务,处于等待状态。
  • 如果这些半连接的握手请求是恶意程序发出,并且持续不断,那么就会导致服务端较长时间内丧失服务功能——这就形成了DoS(Denial of Service)拒绝服务攻击。这种攻击方式就称为SYN泛洪(SYN flood)攻击

处理:

  • 最常用的一个手段就是优化主机系统设置。比如降低SYN timeout时间,使得主机尽快释放半连接的占用或者采用SYN cookie设置,如果短时间内收到了某个IP的重复SYN请求,我们就认为受到了攻击。我们合理的采用防火墙设置等外部网络也可以进行拦截。

3、TCP、UDP报头

  • TCP报头
    TCP报头

  • 源端口和目的端口:各占2个字节。

  • 序号:占4字节。序号范围是0~2^32-1。TCP是面向字节流的,TCP连接中传送的字节流中的每个字节都按顺序编号。整个要传送的字节流的起始序号必须要在连接建立时设置。首部中的序号字段值指的是本报文段所发送的数据的第一个字节的序号。

  • 确认号:4个字节,是期望收到对方下一个报文段的第一个数据字节的序号。
    若确认号=N,则表明:到序号N-1为止的所有数据都已正确收到。
    4.数据偏移:4位。指出TCP报文段的数据起始处距离报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。由于首部中还有长度不确定的选项字段,因此数据偏移字段是必要的。单位是32位字,也就是4字节,4位二进制最大表示15,所以数据偏移也就是TCP首部最大60字节

  • 保留:6位
    下面有6个控制位说明本报文段的性质

  • 紧急URG:1位
    当URG=1时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据),而不要按原来的排队顺序来传送。例如,已经发送了很长的一个程序在远地的主机上运行。但后来发现了一些问题,需要取消该程序的运行。因此用户从键盘发出中断命令(Control+c)。如果不使用紧急数据,那么这两个字符将存储在接收TCP的缓存末尾。只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程。这样做就浪费了许多时间。

  • URG置为1时,发送应用进程就告诉发送方的TCP有紧急数据要传送。于是发送方TCP就把紧急数据插入到本报文段数据的最前面,而在紧急数据后面的数据仍时普通数据。这时要与首部中紧急指针字段配合使用。

  • 确认ACK 仅当ACK=1时确认号字段才有效。当ACK=0时,确认号无效。TCP规定,在连接建立后所有的传送的报文段都必须把ACK置1。

  • 推送PSH 当两个应用进程进行交互式的通信时,有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应。在这种情况下,TCP就可以使用推送操作。

  • 这时,发送方TCP把PSH置1,并立即创建一个报文段发送出去。接收方TCP收到PSH=1的报文段,就尽快地交付接收应用进程,而不再等到整个缓存都填满了后向上交付。虽然应用程序可以选择推送操作,但推送还很少使用。

  • 复位RST
    tcp连接出现严重差错时释放连接,然后重新建立连接。而可以用来拒绝一个非法的报文段或拒绝打开一个连接。
    当RST=1时,表明TCP连接中出现严重差错(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个连接。

  • 同步SYN
    在连接建立时用来同步序号。当SYN=1而ACK=0时,表明这是一个连接请求报文段。对方若同意建立连接,则应在相应的报文段中使用SYN=1和ACK=1。因此,SYN置为1就表示这是一个连接请求或连接接受保温。

  • 终止FIN
    用来释放一个连接。当FIN=1时,表明此报文段的发送方的数据已发送完毕,并要求释放运输连接。

  • 窗口 占2字节。窗口值是【0,2^16-1]之间的整数。窗口指的是发送本报文段的一方的接收窗口(而不是自己的发送窗口)。窗口值告诉对方: 从本报文段首部中的确认号算起,接收方目前允许对方发送的数据量。之所以要有这个限制,是因为接收方的数据缓存空间是有限的。总之,窗口值作为接收方让发送方设置其发送窗口的依据。并且窗口值是经常在动态变化着。

  • 检验和:2字节。检验范围包括首部和数据两部分。和UDP用户数据报一样,在计算校验和 时,要在TCP报文段加上12字节的伪首部。

  • 紧急指针:2字节。紧急指针仅在URG=1时才有意义,它指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据)。因此,紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据都处理完时,TCP就告诉应用程序恢复到正常操作。值得注意的是,即使窗口为零时也可发送紧急数据。

  • 选项:长度可变,最长可达40字节。当没有使用“选项”时,TCP的首部长度是20字节。

    1. MSS 最大报文段长度
      MSS最大报文段长度(数据字段的最大长度,默认是536字节)。MSS不宜设的太大也不宜设的太小。若选择太小,极端情况下,TCP报文段只含有1字节数据,在IP层传输的数据报的开销至少有40字节(包括TCP报文段的首部和IP数据报的首部)。这样,网络的利用率就不会超过1/41。若TCP报文段非常长,那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传,这些也都会使开销增大。
      因此MSS应尽可能大,只要在IP层传输时不需要再分片就行。在连接建立过程中,双方都把自己能够支持的MSS接入这一字段,以后就按照这个数值传送数据。
    2. 窗口扩大
      窗口扩大选项是为了扩大窗口。TCP首部中窗口字段长度是16位,因此最大窗口大小就是64k字节。对于包含卫星信道的网络可能是不够用的。可以在双方初始建立TCP连接的时候就进行协商。
    3. 时间戳(计算RTT,防止序号绕回)
      A. 用来计算往返时间RTT。发送方在发送报文段时把当前时钟的时间值放入时间戳字段,接收方在确认该报文段时把时间戳字段值复制到时间戳回送回答字段。因此,发送方在收到确认报文后,可以准确地计算RTT来。
    4. 选择确认选项
  • UDP报头UDP报头

  • UDP协议分为首部字段和数据字段,其中首部字段只占用8个字节,分别是个占用两个字节的源端口、目的端口、长度和检验和。

3、为什么TCP不是两次?为什么不是四次?

  • 三次握手是为了防止,客户端的请求报文在网络滞留,客户端超时重传了请求报文,服务端建立连接,传输数据,释放连接之后,服务器又收到了客户端滞留的请求报文,建立连接一直等待客户端发送数据。
    服务器对客户端的请求进行回应(第二次握手)后,就会理所当然的认为连接已建立,而如果客户端并没有收到服务器的回应呢?此时,客户端仍认为连接未建立,服务器会对已建立的连接保存必要的资源,如果大量的这种情况,服务器会崩溃。

4、三次握手分别失败

5、四次挥手

在这里插入图片描述

  • 四次挥手首先由客户端K发起,
  • 客户端向服务端发送FIN报文,并停止发送数据,客户端进入FIN_WAIT_1状态
  • 服务端收到FIN报文后,发送ACK到客户端确认,服务端自己进入CLOSE_WAIT,
  • 当客户端收到ACK时切换为FIN_WAIT2状态
  • 当服务器端数据传输完毕之后,发送FIN到客户端,自己进入LAST_ACK状态
  • 客户端收到FIN后,发送ACK到服务端,自己进入TIME_WAIT状态
  • 服务端收到ACK后进入CLOSE状态

6、MSL时间

  • MSL是Maximum Segment Lifetime英文的缩写,中文可以译为“报文最大生存时间”,他是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。因为tcp报文(segment)是ip数据报(datagram)的数据部分
  • 2MSL即两倍的MSL,TCP的TIME_WAIT状态也称为2MSL等待状态,当TCP的一端发起主动关闭,在发出最后一个ACK包后,即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态,必须在此状态上停留两倍的MSL时间,等待2MSL时间主要目的是怕最后一个 ACK包对方没收到,那么对方在超时后将重发第三次握手的FIN包,主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态 时两端的端口不能使用,要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置 SO_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。

7、http和https的区别

  1. HTTP协议是以明文的方式在网络中传输数据,而HTTPS协议传输的数据则是经过TLS加
    密后的,HTTPS具有更高的安全性
  2. HTTPS 在TCP三次握手阶段之后,还需要进行SSL的handshake,协商加密使用的对称
    加密密钥
  3. HTTPS 协议需要服务端申请证书,浏览器端安装对应的根证书
  4. HTTP协议端口是80, HTTPS协议端口是443
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

quchen528

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值