对TCP说三道四

有一天,a有事情想跟b商量就问b“有时间么,想和你聊一下天”,b想了一会发现自己能抽出时间就回复a说“可以啊,并把具体时间告诉了a”,a收到消息后就高高兴兴的去安排自己的时间,并告知b“我的时间也安排好了,可以说话了”,然后a和b噼里啪啦的说了好长时间,最后a的话终于说完了,想要结束聊天了。于是

a说“我的话说完了”,b这个时候就有两种可能性了:b的话没说完和b的话说完了。

1.如果b的话没说完,b就要跟a说“我的话还没说完了,你还得多听一会,等我说完了着”,然后b就噼里啪啦的又跟a说了一堆事情,a就在那里安静的听着,终于b说完了,这个时候b就跟a回了句“好了,我的事情终于说完了,你可以去忙其他的事了”,然后a就准备去忙其他的事情,但是他不知道b是不是还在想着这次谈话,出于礼貌和不放心,a还是决定再回一句让b也去忙其他的,于是a就给b回了一句“我要去忙其他的了,你也去忙你的其他的事吧”。于是这次谈话就愉快的结束了。

2.如果b的话说完了,b就说“好,我的话也说完了,你去忙其他的事吧”,a收到了b的回话,a就准备去忙其他的事情,但是他不知道b是不是还在关注着这次谈话,出于礼貌和不放心,a还是决定再回一句让b去忙其他的,于是a就给b回了一句“我要去忙其他的了,你也去忙你的其他的事吧”。

有这次谈话,他想到了计算机的世界,计算机a要和计算机b建立链接,如果b刚好有资源就可以分配一段资源(建立进程,分配端口号等)去处理a的请求,他们之间通过三次TCP链接后就正式传输数据,处理数据。断开连接则有可能是b请求断开链接也有可能是a,但是过程是类似的,假设是a的数据传完了,就请求断开链接,b要给a的答复就有两种可能了,如果b还有数据没传完要断开链接总共就得四次TCP链接了,如果b的数据传完了要断开链接其实三次TCP链接就可以完事了。

由于考虑到网络的不稳定性、TCP的不可靠性以及充分利用计算机资源等原因,人们就给计算机设定了一个合理的最高等待时间限度,如果网络断了,过了这个时间限度还没收到彼此回复,双方计算机就主动结束这次通信,终止这次通信所带来的资源开销。上例中a最后一次发消息给b也是由于b在这个时间限度内不会主动让出这次通信所占用的资源,为了让b更早的让出这些资源,a就及时发一个消息主动告诉b,让b腾出这段资源去忙其他的。a发送完最后一条消息后等到时间到了这个时间段就也让出因这次通信所占用的资源。

计算机本来是笨的,然而人类很聪明,就让计算机变得很聪明;也让计算机变得很懂礼貌,然而计算机却让人类变得越来越不懂礼貌,越来越虚假。晨曦初露,人渐醒,原来只是整个世界打了个盹,做了个不近人情的交易!”醒来的那个人,揉了揉眼,不小心碰到了键盘,借着微光,无力地瞅了一眼横在面前的那副图,心想:“Y的,这世界和这图与我有关么,还害得我一宿没睡好?”于是就又无精打采地趴着睡了。

时间: 2024-12-18 02:59:37

对TCP说三道四的相关文章

对TCP说三道四(三次握手)

夜朦胧,人方静,无聊的人打开了无聊的电脑看到了一张无聊的图,想着想着就睡着了,梦到了人a和人b的一次聊天. 有一天,a有事情想跟b商量就问b“有时间么,想和你聊一下天”,b想了一会发现自己能抽出时间就回复a说“可以啊,并把具体时间告诉了a”,a收到消息后就高高兴兴的去安排自己的时间,并告知b“我的时间也安排好了,可以说话了”,然后a和b噼里啪啦的说了好长时间,最后a的话终于说完了,想要结束聊天了.于是 a说“我的话说完了”,b这个时候就有两种可能性了:b的话没说完和b的话说完了. 1.如果b的话

TCP拥塞控制机制

我们知道TCP是拥有拥塞控制机制的,而UDP是没有的,为什么需要拥塞控制机制呢,就是防止丢包过多导致传输效率低下.网络中传输的包太多,路由器的缓存又不够,每一个发送端都以自己想要的发送速率发送包,自然会导致网络拥塞.所以我TCP就包括了拥塞控制机制. 有几种拥塞控制方法? 2种 1.端到端拥塞控制.网络层没有显示的告知传输层此时网络出现拥塞了,传输层通过报文段的丢失(超时或3次冗余确认得知)认为网络出现拥塞了,TCP会缩减其拥塞窗口,减小发送速率. 2.网络辅助的拥塞控制.网络层显示的告知发送端

winform学习日志(二十三)---------------socket(TCP)发送文件

一:由于在上一个随笔的基础之上拓展的所以直接上代码,客户端: using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System.Net.Sockets; using Sys

TCP四次挥手(断开连接)(未完待续)

正常情况下,调用close(),其中产生的一个效果就是发送FIN. 断开为什么需要四次握手: TCP协议是一种面向连接的.可靠的.基于字节流的运输层通信协议.TCP是全双工模式,这就意味着,当主机1发出FIN报文段时,只是表示主机1已经没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕了:但是,这个时候主机1还是可以接受来自主机2的数据:当主机2返回ACK报文段时,表示它已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的:当主机2也发送了FIN报文段时,这个时候就表示主

JAVA网络编程TCP通信

Socket简介: Socket称为"套接字",描述IP地址和端口.在Internet上的主机一般运行多个服务软件,同时提供几种服务,每种服务都打开一个Socket,并绑定在一个端口上,不同的端口对应于不同的服务.Socket和ServerSocket类位于java.net包中.ServerSocket用于服务端,Socket是建立网络连接时使用的.连接成功时,应用程序两端都会产生一个Socket实例,通过操作这个实例完成所需会话. Socket常用方法: -int getLocalP

《TCP/IP具体解释》读书笔记(22章)-TCP的坚持定时器

TCP通过让接收方指明希望从发送方接收的数据字节数(即窗体大小)来进行流量控制. 假设窗体大小为0会发生什么情况呢?这将有效阻止发送方传送数据,直到窗体变为非0为止. ACK的传输并不可靠,也就是说,TCP不正确ACK报文段进行确认,TCP仅仅确认那些包括有数据的ACK报文段. 1.坚持定时器 假设一个场景:假设一个确认丢失了,则两方就有可能由于等待对方而使连接终止,接收方等待接收数据(由于它已经向发送方通告了一个非0的窗体),而发送方在等待同意它继续发送数据的窗体更新.为防止这种死锁情况的发生

使用TCP时序图解释BBR拥塞控制算法的几个细节

周六,由于要赶一个月底的Deadline,因此选择了在家VPN加班,大半夜就爬起来跑用例,抓数据...自然也就没有时间写文章和外出耍了...不过利用周日的午夜时间(不要问我为什么可以连续24小时不睡觉,因为我觉得吃饭睡觉是负担),我决定把工作上的事情先放下,还是要把每周至少一文补上,这已经成了习惯.由于上周实在太忙乱,所以自然根本没有更多的时间去思考一些"与工作无关且深入"的东西,我指的与工作无关并非意味着与IT,与互联网无关,只是意味着不是目前我在做的.比如在两年前,VPN,PKI这

可以将TCP BBR算法模块化到低版本内核取代锐速吗

上周的文章引发了比较火爆的争论并带来了争议,我比较满意或者遗憾,尽管如此,如果有人真的能明白在文章的背后我真正想表达的意思,我也就深感欣慰了.还像往常一样,我花周末的时间来总结结束,写点技术散文,同时我希望能在技术上引发同样的争论.        在跟温州皮鞋厂老板聊天时,老板让我从非技术角度重新思考了Google的BBR算法.        很多测试似乎表明BBR的表现非常不错,虽不能保证包打天下,至少相比锐速而言,它是免费的啊,那么疑问也就随之而来了,既然BBR是免费的,且效果不错,那么那些

【Linux 网络编程】常用TCP/IP网络编程函数

(1)函数socket 1 /**************************************************************** 2 ** 功能:创建一个套接字用于通信 3 ** 参数:domain 指定通信协议族 4 ** type 指定socket类型,流式套接字 SOCK_STREAM 5 ** 数据报套接字 SOCKDGRAM 6 ** 原始套接字 SOCKRAW 7 ** protocol 协议类型 (习惯上填写0) 8 ** 返回值:成功返回非负整数,它