网络：传输层协议：TCP&&UDP

最新推荐文章于 2024-04-22 14:57:33 发布
最新推荐文章于 2024-04-22 14:57:33 发布
阅读量395 收藏 2
点赞数 6
文章标签： 网络 网络通信 tcpip udp linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_43745617/article/details/117657361
版权

文章目录

UDP

1.UDP特点

  1. 传输层协议
    属于传输层协议;
  2. 无连接
    知道对端的IP和端口号就直接进行传输, 不需要建立连接;
  3. 不可靠传输
    没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;
  4. 面向数据报
    不能够灵活的控制读写数据的次数和数量。

面向数据报

应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并；比如：

  • 用UDP传输100个字节的数据:
    如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节;

2.UDP协议段格式

  • UDP的协议段为定长报头，为8字节；
  • 包含16位源端口号，16位目的端口号，16位UDP长度，16位UDP检验和。
    在这里插入图片描述
  1. 源端口号：该报头从哪里向服务器请求数据；标识一台主机发起通信的那个进程；
  2. 目的端口号：该报头向哪里请求数据，标识另一台主机接受通信的那个进程；
  3. UDP长度：表示整个数据报(UDP首部+UDP数据)的最大长度;
  4. UDP检验和：如果检验和出错, 就会直接丢弃。

3.UDP的缓冲区

  • UDP没有真正意义上的发送缓冲区。调用sendto会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作；

  • UDP具有接收缓冲区。但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致； 如果缓冲区满，再到达的UDP数据就会被丢弃；

  • UDP的socket既能读, 也能写, 这个概念叫做全双工。

4.UDP使用注意事项

  • 我们注意到，UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。64K在当今的互联网环境下，是一个非常小的数字。
  • 如果我们需要传输的数据超过64K，就需要在应用层手动的分包，多次发送，并在接收端手动拼装；

5.基于UDP的应用层协议

  • NFS: 网络文件系统
  • TFTP: 简单文件传输协议
  • DHCP: 动态主机配置协议
  • BOOTP: 启动协议(用于无盘设备启动)
  • DNS: 域名解析协议
  • 自己写UDP程序时自定义的应用层协议;

TCP

1.TCP特点

  1. 传输层协议
  2. 有连接
    知道对端的IP和端口号后需要与对端建立连接，然后再传输数据;
  3. 可靠传输
    有确认应答机制，超时重传机制，连接管理机制来保证数据的可靠传输；
  4. 面向字节流
    能够灵活的控制读写数据的次数和数量。

2.TCP协议段格式

  • 包含16位源端口号，16位目的端口号，32位序号，32位确认序号，4位首部长度，16位窗口大小，16位检验和，15位紧急指针，以及数据。
    在这里插入图片描述
  1. 源端口号：该报头从哪里向服务器请求数据；标识一台主机发起通信的那个进程；
  2. 目的端口号：该报头向哪里请求数据，标识另一台主机接受通信的那个进程；
  3. 32位序号： 对数据进行编号，保证发送端到接收端的数据按序到达；
  4. 32位确认序号：保证接收端确认应答(ACK)，确认序号=已发送的数据最大编号+1；
    TCP通信是全双工，如果发送端与接收端同时工作，发送端关心确认序号，以便继续向接收端发送数据；接收端关心序号，以便向发送端进行ACK。
  5. 4位首部长度：取值范围0101（5）~1111（15）；代表整个报头一共有多少个4字节；最小为0101是因为最小为20字节，选项最多为40字节；
  6. 6位标志位:
  • URG: 紧急指针是否有效
  • ACK: 确认序号是否有效
  • PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走（催促接收端读数据）
  • RST: 在建立连接失败时，对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
  • SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
  • FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
  1. 16位窗口大小：代表自身 接收缓冲区当中剩余空间的大小；
  2. 16位检验和：由发送端填充，CRC校验。接收端校验不通过,，则认为数据有问题，直接丢弃。此处的检验和不光包含TCP首部，也包含TCP数据部分；
  3. 16位紧急指针：一个偏移量，标识哪部分数据是紧急数据。紧急数据是需要被优先处理的数据。

以下内容均是保证TCP传输时的可靠性相关

3.TCP的三种机制

（1）确认应答(ACK)机制

  • TCP将每个字节的数据都进行了编号。即为序列号。
    在这里插入图片描述

  • 每一个ACK都带有对应的确认序列号， 意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开始发。
    在这里插入图片描述
    1. ACK本身不需要ACK；
    2.不存在绝对可靠，因为始终存在最新的一条消息没有被ACK；

（2）超时重传机制

超时重传的唯一标准就是发送数据的一端是否收到接收端的ACK；

  • 主机A发送数据给B之后， 可能因为网络拥堵等原因，数据无法到达主机B；如果主机A在一个特定时间间隔内没有收到B发来的确认应答， 就会进行重发；
    在这里插入图片描述
  • 如果主机B发送的ACK丢失，主机A未收到B发来的ACK, 也可能认为数据丢失了;在这里插入图片描述
    TCP为了保证较高性能的通信, 会动态计算最大超时时间
  • Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍；
  • 如果重发一次之后, 仍然得不到应答, 等待 2* 500ms 后再进行重传；如果仍然得不到应答, 等待 4* 500ms 进行重传；依次类推, 以指数形式递增，累计到一定的重传次数, TCP会认为网络或者对端主机出现异常, 强制关闭连接。
（3）连接管理机制
  • 在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接。
  • 为何是三次握手：服务器是一对多的，在建立连接时最担心的总是最后一次报文的发送丢失，如果是一次或两次握手，容易造成SYN洪水攻击（向服务器端发送大量SYN连接请求，造成服务器瘫痪）；如果是四次，最后一次报文丢失会造成服务器挂载大量无用链接，在极端情况下服务器崩溃（如断网），更多次数便无意义，都与三次与四次是同等作用。
  • 为何是四次握手：因为TCP是全双工通信，客户端主动要求断开连接（向服务器发送FIN）后服务器端会确认收到断开连接的请求（向客户端发送ACK）；服务器端也请求一次断开连接（向客户端发送FIN），客户端也确认收到断开连接的请求（向服务器发送ACK）；之后连接正式断开。
    在这里插入图片描述
    服务端状态转化:
  1. [CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接；
  2. [LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文；
  3. [SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了；
  4. [ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT；
  5. [CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)。
  6. [LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK, 彻底关闭连接。

客户端状态转化:

  1. [CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段;
  2. [SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;
  3. [ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段, 同时进入FIN_WAIT_1;
  4. [FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服务器的结束报文段;
  5. [FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK;
  6. [TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态。

在三次挥手与四次握手时，最重要的总是最后一次客户端向服务器端发送ACK，如果处理不慎，这种情况在三次挥手会造成服务器链接建立误判，四次挥手时会让服务器的链接无法关闭。接下来谈谈如何解决这两个问题。

  • 三次握手最后一次报文丢失：只有在服务器端正式收到ACK（确认应答）时，才会建立链接。这个问题比件容易解决。
  • 四次挥手最后一次报文丢失：客户端发送确定断开连接的ACK后要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间，如果该ACK丢失服务器会重发FIN，若客户端再收到FIN报文，便重发ACK；这个过程中，客户端没有收到消息便是好消息。

4.TCP传输的两种状态

（1）TIME_WAIT状态

TIME_WAIT状态是主动断开连接的一方（通常是客户端，后面用客户端代替）在四次挥手进行最后一次ACK确认断开连接之前的状态。

如果没有TIME_WAIT

  • 客户端如果立马断开连接，如果ACK丢失，服务器端便收不到ACK，服务器端的链接便无法关闭。

TIME_WAIT的作用

  • 客户端发送确定断开连接的ACK后进入TIME_WAIT，等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间，如果该ACK丢失服务器会重发FIN，若客户端再收到FIN报文，便重发ACK；这个过程中，客户端没有收到消息便是好消息。

TIME_WAIT的意义

  • 尽量保证最后一个ACK被服务器端收到。让服务器的资源尽快释放；
  • 保证历史数据尽快在网络中消散。
（2）CLOSE_WAIT 状态

CLOSE_WAIT状态出现在四次挥手中客户端主动请求断开连接第一次发送FIN给服务器端后服务器端的状态，这时服务器端准备关闭连接。

  • 在服务器端进入CLOSE_WAIT状态时，服务器准备断开连接，关闭套接字；在服务器给客户端发送FIN并且客户端ACK之后，服务器调用close()函数关闭套接字，链接正式断开，服务器进入CLOSE状态。
  • 对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成。 只需要加上对应的 close 即可解决问题。

5.滑动窗口

  • 刚才我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答。收到ACK后再发送下一个数据段。
    这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候。

  • 既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。
    在这里插入图片描述
    滑动窗口

  1. 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四个段)；
  2. 发送前四个段的时候, 不需要等待任何ACK, 直接发送；
  3. 收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推；
  4. 操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉；
  5. 窗口越大, 则网络的吞吐率就越高。
    在这里插入图片描述
    当然，滑动窗口也存在丢包问题，以下谈谈如何解决

情况1： 数据包已经抵达, ACK被丢了。

  • 这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认;
    在这里插入图片描述
    情况2：数据包直接丢失。
    高速重发控制；也叫快重传

  • 当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK；

  • 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;

  • 这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中。
    在这里插入图片描述

6.流量控制

接收端处理数据的速度是有限的。如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control);

流量控制

  • 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端;
  • 窗口大小字段越大, 说明网络的吞吐量越高;
  • 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端；发送端接受到这个窗口之后, 就会减慢自己的发送速度；
  • 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端。
  • TCP首部40字节选项中包含了一个窗口扩大因子M, 实际窗口大小是窗口字段的值左移 M 位;
    在这里插入图片描述

7.拥塞控制

网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下, 贸然发送大量的数据，很有可能使网络雪上加霜。

慢启动

  • TCP引入慢启动机制, 先发少量的数据，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据；
  • “慢启动” 只是指初使时慢，增长速度非常快。

拥塞窗口

  • 发送开始的时候, 定义拥塞窗口大小为1;
  • 每次收到一个ACK应答, 拥塞窗口扩大一杯，以指数方式增长;
  • 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;
  • 为了不增长的那么快, 不能使拥塞窗口单纯的加倍，需要设置慢启动的阈值；当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长；
  • 少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞。当TCP通信开始后, 网络吞吐量会逐渐上升；随着网络发生拥堵, 吞吐量会立刻下降；
  • 当TCP开始启动的时候, 慢启动阈值等于窗口最大值;在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1。

在这里插入图片描述

我们之前还了解了“滑动窗口”，那么窗口最终的的大小该如何选择呢？

  • 最终窗口大小在“滑动窗口”和“拥塞窗口”中取最小值。

8.延迟应答

如果接收端主机立刻返回ACK应答, 这时候返回的窗口可能比较小。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;

延迟应答

  • 比如接收缓冲区有1M，一次收到了600K的数据;；如果立刻应答, 返回的窗口就是400K；但实际上可能接收端10ms就把600K数据从缓冲区消费掉了；这样会发送很多次多余的ACK，造成效率降低、资源浪费。
  • 在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来；如果接收端稍微等一会再应答, 比如等待10ms再应答,数据从缓冲区消费掉之后缓冲区空,那么这个时候返回的窗口大小就是1M;

不是所有的包都可以延迟应答

  • 数量限制: 每隔N个包就应答一次;
    时间限制: 超过最大延迟时间就应答一次;
    具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms;

9.捎带应答

  • 在延迟应答的基础上, 客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”；那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端。

  • 不仅ACK可以搭数据的“顺风车”，下图中FIN也是搭了ACK的“顺风车”。
    在这里插入图片描述

10.面向字节流

创建一个TCP的socket, 同时会在内核中创建一个发送缓冲区和一个接收缓冲区；调用write时, 数据会先写入发送缓冲区中。

  • 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
  • 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
  • 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;
  • 另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工。

由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:

  • 写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节。
  • 读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次。

11.粘包问题

  • 粘包问题中的 “包” , 是指的应用层的数据包。
  • 在TCP的协议报头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段。站在传输层的角度, TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。
  • 站在应用层的角度, 看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分是一个完整的数据包。

解决：明确两个包之间的边界

  • 对于定长的包, 保证每次都按固定大小读取即可; 例如上面的request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(request)依次读取即可；
  • 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置；
  • 对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序员自己来定的, 只要保证分隔符不和正文冲突即可)。

PS：UDP不存在“粘包问题”

  • 对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在。同时, UDP是一个一个把数据交付给应用层。就有很明确的数据边界；
  • 站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收。不会出现"半个"的情况。

12.TCP异常情况

  • 进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
    机器重启: 和进程终止的情况相同.
  • 机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset。即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放。
  • 另外, 应用层的某些协议, 也有一些这样的检测机制。在HTTP长连接中, 也会定期检测对方的状态。 例如QQ, 在QQ断线之后, 也会定期尝试重新连接。

13.TCP小结

为什么TCP这么复杂? 因为要保证可靠性, 同时又尽可能的提高性能.
可靠性:

  • 校验和
  • 序列号(按序到达)
  • 确认应答
  • 超时重发
  • 连接管理
  • 流量控制
  • 拥塞控制

提高性能:

  • 滑动窗口
  • 快速重传
  • 延迟应答
  • 捎带应答

其他:

  • 定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等)。
    超时重传定时器负责超时重传机制的定时；保活计时器负责极端条件下对连接的生存时间进行管理；TIME_WAIT定时器负责主动断开连接的一方保持TIME_WAIT状态的定时。

14.基于TCP应用层协议

HTTP；HTTPS；SSH；Telnet；FTP；SMTP等；
当然, 也包括你自己写TCP程序时自定义的应用层协议。

TCP/UDP对比

TCP是可靠连接, 那么是不是TCP一定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进行比较。

  • TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景；
  • UDP用于对高速传输和实时性要求较高的通信领域, 例如早期的QQ, 视频传输等。 另外UDP可以用于广播;

TCP和UDP都是工具, 什么时机用, 具体怎么用, 要根据具体的需求场景去判定。

mbf330
关注
  • 6
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
第3章 传输层协议UDP和TCP
08-15
3.1 端到端通信和端口号 3.2 用户数据报协议UDP 3.3 传输控制协议TCP 3.4 TCP与UDP的比较 习题
传输层：深入研究传输层的工作原理和技术，包括TCP和UDP协议.md
10-28
传输层：深入研究传输层的工作原理和技术，包括TCP和UDP协议
linux 虚拟机大量udp请求失败_linux遭受UDP攻击解决办法
weixin_29063035的博客
02-17 837
前几天朋友的网站流量很大，导致无法访问。去IDC查看，服务器已经DOWN掉了。重启后使用bandwidth查看近来的流量状况，发现是由于UDP的流量达到峰值导致。系统为Centos 5.41、下载安装iftop查看具体流量来源。wget http://www.ex-parrot.com/~pdw/iftop/iftop-0.17.tar.gz #下载源码安装包tar -zvxf iftop-0....
udp服务雪崩测试与分析
认知 行动 坚持
03-09 5673
我们知道， udp socket的接收缓冲区大小是有限的， 可以查到最大值。 以server端为例， 如果server端socket接收缓冲区满了， 那么client端新进的请求不会得到及时处理， 出现丢包。 即使server端的socket的接收缓冲区没有满， 但仍有一些请求在其中排队， 那么从client端发过来的新请求， 也自然会排队， 很可能没有等到server端来得及去re...
开发bug之udp报文冲垮交换机网络
CoderLife9192的专栏
02-21 1015
新年刚开始就遇到这怪事，本来集群测试的好好的，两个星期都啥事的，早上来一误操作，导致某服务msgrcv的消息队列id被删除了，而机器上有多个这样的进程同时在阻塞等待消息队列上的数据。。。。 代码逻辑如下 while (1) {   ret = msgrcv(id, msg, 0, 0);   if (ret        dog_write(warn, "msgrcv erro
【网络编程】TCP/UDP协议（传输层特性）
Anton的博客
06-05 322
TCP/UDP协议（传输层特性）背景知识端口号UDP分析报头UDP特点面向数据报基于UDP的应用层协议TCPTCP报头分析确认应答机制超时重传机制连接管理机制TIME_WAITCLOSE_WAIT滑动窗口流量控制拥塞控制（网络问题） 背景知识 端口号 在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信(可以通过netstat -n查看) 并且端口号是有范围划分的： 0 - 1023: 知名端口号, HTTP, FTP, SS
传输层协议UDP和TCP
MEANSWER的博客
06-06 501
传输层协议UDP和TCP1. 长短链接2. UDP协议2.1 UDP协议端格式2.2 UDP的特点3. TCP协议3.1 详谈TCP协议段格式3.2 确认应答(ACK)机制 1. 长短链接 短链接：版本号HTTP/1.0，每一次进行三次握手，然后建立连接，发送request，返回response，但是里面只有一个body，就断开连接了，下一次请求资源（比如请求网页：网页的本身是由多种“元素”所构成的，包括文本、图片、音频、视频等），又需要再次建立连接，这样两者之间建立连接的成本就会特别的高。 长链接：版本
传输层协议（TCP, UDP）
agentky的博客
08-30 992
传输层定义了主机应用程序之间端到端的连通性。传输层中最为常见的两个协议分别是传输控制协议TCP（Transmission Control Protocol）和用户数据报协议UDP（User Datagram Protocol）。 TCP TCP是一种面向连接的传输层协议，提供可靠的传输服务。 TCP通过端口号区分不同网络服务 TCP允许一个主机同时运行多个应用进程。每台主机可以拥有多个应用端口，每对端口号，源和目标IP地址的组合唯一地标识了一个会话。端口分为知名端口和动态端口。有些网络服务会使用固定的端口
传输层协议之TCP和UDP详细说明
崔崇鑫的博客，你linux/云运维工作中的百科全书。
12-16 4527
传输层 传输层功能介绍 传输层： 标明上层所使用什么样的应用 端口号（2字节） SYN（1bit） ACK（1bit） 传输层的功能： session multiplexing——会话多路复用 Identification of different applications——识别不同申请 Segmentation*——分割 Flow control*——流量控制 Connection-oriented*——面向连接 Reliability*——可靠性 会话多路复用 说明 为什么一个IP地址可
关于传输层的TCP/UDP协议
weixin_43786976的博客
03-29 298
单纯的学习笔记。 在计算机网络中，传输层位于网络层之上，应用层之下。网络层负责提供主机与主机之间的逻辑通信，而传输层负责进程与进程之间的逻辑通信。传输层位于网络层之上，依赖和利用网络层提供的服务，对网络层的服务进行进一步的加强，为应用层提供服务。 主要提供了下面的服务： 1.复用/分用 2.可靠数据传输机制 3.流量控制机制 4.拥塞控制机制 不同的传输层协议提供的服务功能是不一样的。 ...
传输层概念 TCP协议 UDP协议 TCP与UDP的区别
04-09
传输层协议
Android中实现TCP和UDP传输实例
01-20
在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能。应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，然后TCP把数据流分割成适当长度的报文段（通常受该计算机连接的网络的数据链路层的最大...
实验3 传输层与应用层协议.docx
02-06
1、捕获TCP三次握手的过程，说明其原理。 2、捕获HTTP工作过程，分析HTTP协议。 3、捕获UDP协议包，写出其格式。 4、捕获DNS数据包，写出DNS工作原理。
._locked勒索病毒的最新威胁：如何恢复您的数据？
weixin_13318844580的博客
04-16 839
这些勒索病毒往往攻击入侵的目标基本是Windows系统的服务器，包括一些市面上常见的业务应用软件，例如：金蝶软件数据库，用友软件数据库，管家婆软件数据库，速达软件数据库，科脉软件数据库，海典软件数据库，思迅软件数据库，OA软件数据库，ERP软件数据库，自建网站的数据库等，均是其攻击加密的常见目标文件，所以有以上这些业务应用软件的服务器更应该注意做好服务器安全加固及数据备份工作。近年来，网络安全问题日益凸显，各种勒索病毒层出不穷，其中._locked勒索病毒以其独特的攻击方式和广泛的传播范围引起了广泛关注。
网络安全之反弹Shell
小飞的博客
04-12 1238
在网络安全和渗透测试领域，“正向Shell”（Forward Shell）和"反向Shell"（Reverse Shell）是两种常用的技术手段，用于建立远程访问目标计算机的会话。这两种技术都可以让攻击者在成功渗透目标系统后执行命令，但它们在建立连接的方式上有所不同。
DMZ是什么？它是如何工作的？
久绊A的博客
04-16 560
DMZ，中文通常译为“隔离区”或“非军事化区”，是在网络安全领域中用来描述一个逻辑或物理的网络子段，这个子段通常位于组织的内部网络和外部网络（如互联网）之间。DMZ的主要目的是提供一个受限制且受控的环境，允许对外提供服务的服务器放置在此区域，从而在一定程度上保护内部网络的安全。
TCP和UDP
hay23455的博客
04-19 323
UDP是一种“随性的协议”，它会把你要发送的信息直接扔到网络上，不太关心是否准确送到，就像丢一颗石头进湖里，不会在意湖里有没有人接住。TCP是一种“细心的协议”，它负责确保你发送的信息能够完整、按顺序地到达目的地，就像快递员送货一样，肯定要确认收货人收到了。当你下载文件、发邮件或者浏览网页时，通常会使用TCP来保证数据传输完整、有序。在一些对速度要求高、能容忍少量数据丢失的应用中使用，比如视频会议、在线游戏等。
Verilog 不可综合部分
最新发布
Arthur...J的博客
04-22 132
Verilog中存在部分用于仿真验证的子集，只在仿真时使用，因为没有对应的硬件元件，因此不可综合。
nmap使用
2202_75361164的博客
04-16 1196
默认的 sS 是发送一个syn包，只建立TCP链接的第一步，如果收到了目标主机的syn加ack回复，则表示目标主机相应的端口是开放的。而收到复位数据包RST，则表示端口是关闭的。而 sT 是利用三次握手过程来判断端口的状态。它通过发送完整的TCP请求，等待目标主机的回复，收到syn加ack回复，即开放。所以说，sS适用于大规模且快速探测。而 sT 具有更好的准确性，但速度也相应会慢上一些。最大的优点是具备更好的隐蔽性，在面对防火墙的检测上，完整的 tcp 请求比只发syn包的更具有隐蔽性。
对这段文字进行功能需求分析包括任务分解和分析：传输层协议： 2 client 与 local DNS server 之间：UDP； DNS server 之间：TCP；
06-05
1. 确定通信协议：根据场景需求，确定 2 client 与 local DNS server 之间采用 UDP 协议进行通信，DNS server 之间采用 TCP 协议进行通信。 2. 实现 UDP 通信：开发 UDP 通信模块，能够接收来自 2 client 的 DNS ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值