tcp通信测试报告单1——connect和send

Pou光明

已于 2024-12-31 08:41:48 修改

阅读量733

点赞数 22

CC 4.0 BY-SA版权

分类专栏： Linux网络协议栈学习文章标签： tcp/ip 网络协议网络

于 2024-12-03 19:55:20 首次发布

本文链接：https://blog.youkuaiyun.com/ACK_ACK/article/details/144228730

Linux网络协议栈学习专栏收录该内容

11 篇文章

订阅专栏

一、发送测试报告

1.server未启动时&未设置connect超时耗时——2秒

2.通过setsockopt设置连接超时——1.1秒

setsockopt(clientfd, SOL_SOCKET ,SO_SNDTIMEO, (char *)&timeout, sizeof(struct timeval));

3. setsockopt与select搭配服用，效果更佳——setsockopt的时间为超时时间，但是select时间要小于1秒

4.send 接口测试

测试步骤：

①成功建立连接

②然后关闭服务器

③调用send接口发送数据

测试结果：仍可正常发送！没有报错！

二、send 结果原因分析

先明确一个概念：每个TCP socket在内核中都有一个发送缓冲区和一个接收缓冲区，TCP的全双工的工作模式以及TCP的滑动窗口便是依赖于这两个独立的buffer以及此buffer的填充状态。接收缓冲区把数据缓存入内核，应用进程一直没有调用read进行读取的话，此数据会一直缓存在相应 socket的接收缓冲区内。再啰嗦一点，不管进程是否读取socket，对端发来的数据都会经由内核接收并且缓存到socket的内核接收缓冲区之中。 read所做的工作，就是把内核缓冲区中的数据拷贝到应用层用户的buffer里面，仅此而已。进程调用send发送的数据的时候，最简单情况(也是一般情况)，将数据拷贝进入socket的内核发送缓冲区之中，然后send便会在上层返回。换句话说，send返回之时，数据不一定会发送到对端去(和 write写文件有点类似)，send仅仅是把应用层buffer的数据拷贝进socket的内核发送buffer中。后续我会专门用一篇文章介绍 read和send所关联的内核动作。每个UDP socket都有一个接收缓冲区，没有发送缓冲区，从概念上来说就是只要有数据就发，不管对方是否可以正确接收，所以不缓冲，不需要发送缓冲区。

　　接收缓冲区被TCP和UDP用来缓存网络上来的数据，一直保存到应用进程读走为止。对于TCP，如果应用进程一直没有读取，buffer满了之后，发生的动作是：通知对端TCP协议中的窗口关闭。这个便是滑动窗口的实现。保证TCP套接口接收缓冲区不会溢出，从而保证了TCP是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。这就是TCP的流量控制，如果对方无视窗口大小而发出了超过窗口大小的数据，则接收方TCP将丢弃它。 UDP：当套接口接收缓冲区满时，新来的数据报无法进入接收缓冲区，此数据报就被丢弃。UDP是没有流量控制的;快的发送者可以很容易地就淹没慢的接收者，导致接收方的UDP丢弃数据报。

　　以上便是TCP可靠，UDP不可靠的实现。

总结：send发到的是内核发送缓冲区。

send（）只是负责拷贝，拷贝完立即返回，不会等待发送和发送之后的ACK。如果socket出现问题，RST包被反馈回来。在RST包返回之时，如果send（）还没有把数据全部放入内核或者发送出去，那么send（）返回-1，errno被置错误值；如果RST包返回之时，send（）已经返回，那么RST导致的错误会在下一次send（）或者recv（）调用的时候被立即返回。

摘自《https://www.cnblogs.com/sky-heaven/p/11612775.html》

这篇文章还有很多值得学习的地方，之后继续学习！

欢迎关注：