美好乡村建设网站,插画师零基础自学,自己做小程序要钱吗,江油市规划和建设局网站我叫TCP#xff08;Transmission Control Protocol#xff09;也叫传输控制协议。不觉回忆1983年#xff0c;亲手将NCP协议淘汰#xff0c;取而代之的是我#xff0c;成了火遍大江南北的网络红人之一。现如今#xff0c;我感受到前所未有的恐惧#xff0c;因为我一生的敌…我叫TCPTransmission Control Protocol也叫传输控制协议。不觉回忆1983年亲手将NCP协议淘汰取而代之的是我成了火遍大江南北的网络红人之一。现如今我感受到前所未有的恐惧因为我一生的敌人UDP正在赶超我甚至将我取而代之。我的生平我在1974年被我的父亲罗伯特·卡恩和温特·瑟夫设计出来和我一同出生的也是如今的网络红人IP我们是一对亲密无间的组合——TCP/IP我在网络七层模型里的4层——传输层而IP兄弟是负责网络层。我的作用就是负责传输数据并代替NCP协议的工作因为它不能跨系统通讯怎么说呢就是如果大家用了Windos操作系统就没法和MacOs操作系统进行通讯这非常不利于互联网的发展我很抱歉NCP一时被抛弃但是我们依然坚信“物竞天择适者生存”的道理。起初出生时我们并没有大家想象的那么容易。刚出生时的我是非常简陋的我的IP兄弟负责每个机器分配一个IP地址标识。IP兄弟像是为我铺好了康庄大道而我只需要将数据包运输到目的地。而我们也比较争气我的父亲卡恩和瑟夫为我做了一个实验将一个数据包从一端发出经过10万千米的旅程后到达服务端。这个传输过程数据包没有丢失一个字节但是我们的命运和其他伙伴一样新技术或新标准起初总是会受到强烈的抵制。特别是标准化组织ISO推出了著名的ISO七层模型那时我又被强烈的鄙视了一番。不得不说父爱是伟大的他们经过4年时间的不断对我们改进为我和IP兄弟完成了基础框架的搭建。尽管阻碍重重我的父亲卡恩和瑟夫进行了长期的斗争。终于在1983年被美国国防部高级研究计划局决定淘汰NCP协议我和IP兄弟取而代之。这个过程整整过去了10年的时间。我和我的亲兄弟IP终于站稳了脚跟分别负责七层模型里的传输层网络层。现如今接触计算机的朋友们对我一定不陌生。我在网络中扮演着重要角色你们发送的信息基本上都是我在负责的每时每刻都在处理成千上万用户的信息还要安全且无误的传输到指定的地方。这时候你可能反应过来了你用手机电脑等设备对你恋人或者亲人说的话语音视频都是我负责帮你们成功抵达而且是准确无误因为至今正常情况下我没有收到你们错误信息的抱怨。我可以自信地说是印度洋和太平洋之间重要枢纽——马六甲海峡。当然我的亲兄弟IP也是功不可没它为我连通了各个设备搭建好了桥梁那么我根据IP我就能找到准确的人给他发送。而且还划分了网段这样你在浙江给在北京的爱人发信息那我一定是往北走而不是往西或者往南走。你可能会好奇我是怎么做到每时每刻处理成千上万的信息安全且无误地传输到目的地。这得归因于我父亲对我的设计了他们致力于让我成为一个安全且靠谱的“运输卡车”。三次握手机制第一次握手做了什么这第一个安全的设计就是连接机制为了确保能够建立正确的连接大部分情况下我需要三次连接才能建立安全可靠的传输通道。也就是你们常说的“三次握手”连接。首先客户端要和服务端建立TCP连接也就是建立通讯管道。会先发一个SYN报文这是一个请求同步连接的报文发送之后此时的客户端会进入到SYN-SENT状态。如果客户端迟迟收不到服务端的SYN-ACK同步应答报文就会触发超时重传机制重新把刚才的SYN报文重新发送而且重传的SYN报文的序列号都是一样的。你可能会好奇客户端没有收到应答之后多久才会触发重传且需要重传几遍才肯罢手。不同版本的操作系统可能超时时间不同有的 1 秒的也有 3 秒的这个超时时间是写死在内核里的如果想要更改则需要重新编译内核比较麻烦。在 Linux 里客户端的 SYN 报文最大重传次数由 tcp_syn_retries 内核参数控制这个参数是可以自定义的默认值一般是 5所以这个可以是由操作系统来设定的。假如我们设置初始超时重传1秒最大重传次数为5次。那么客户端第一次超时重传是在1秒第二次超时重传是在2秒第三次超时重传是在4秒第四次超时重传是在8秒第五次超时重传是在16秒。我们可以看到规律每次超时时间是上一次的2倍。当到了第五次重传时将继续等待32秒之后服务端还是没有响应ACK客户端将不再发送SYN包然后断开TCP连接。▲图/ 第一次握手超时重传机制第二次握手做了什么第二次握手也就是客户端发送的SYN报文如果服务端收到了就会返回一个SYN-ACK报文给客户端并且服务端进入SYN_RCVD同步已接收状态。此时的SYN-ACK报文做了两件事一件是对第一次握手时做个回应确认报文已经收到。另一个是服务器既然收到了便会发起建立TCP通信管道的连接的报文这个地方是一个发送请求时间如果没有得到ACK回应则会触发超时重传机制。此时如果服务端的SYN_ACK报文发送了之后如果丢失或者某种原因导致客户端没有收到只要客户端没有接收到就会触发超时重传机制会有计时器超过时间没接收到就重传重传SYN报文。当然为了确保稳定不仅客户端会有重传机制服务器也会有超时重传机制重发SYN-ACK报文。在 Linux 下SYN-ACK 报文的最大重传次数由 tcp_synack_retries内核参数决定默认值是 5。▲图/ 第二次握手超时重传机制第三次握手做了什么这个时候客户端收到服务端的ACK应答报文并发起了TCP建立连接请求此时客户端收到并对TCP建立连接得请求发送一个ACK应答报文并且客户端进入ESTABLISH的建立连接状态。我们可以看到此时的第三次握手是基于第二次握手服务端发来的SYN的确认报文如果客户端没有收到那么服务端此时会触发超时重传机制进行重发相同的ACK报文。▲图/ 第三次握手超时重传机制由此我们也可以总结出结论ACK应答报文并不会有重传机制当ACK丢失了由对方发来的SYN报文进行重传。以上就是我的建立连接机制了。你们可能会看起来比较麻烦特别是当今世界如果聊天出现了三次握手的情况你们一定是不耐烦的。然而我这是牺牲了一定的速度来确保安全以及稳定的作用我想人们更多情况下都是求安全且稳定的。四次挥手机制我虽然在一定程度上具有传统且保守的态度但是我一定是力争求稳且有始有终是你们靠谱的伙伴。所以在传输结束时我也有一套安全稳定的断联机制。就是你们俗称的“四次挥手”。第一次挥手做了什么第一次挥手当客户端所有的消息都发送完之后会主动调用close函数然后向服务器发送FIN完成报文试图和服务器断开连接并且状态进入到FIN_WAIT_1状态。客户端不管何种情况只要没有收到ACK报文就会触发超时重传机制重传FIN报文重传次数也是由操作系统 tcp_orphan_retries 参数设置。▲图/ 第一次挥手超时重传机制超时重传到达 tcp_orphan_retries 的次数之后就不再发送FIN报文则会等待上一段时间的2倍之后还是没有收到则直接进入close状态。第二次挥手做了什么第二次挥手服务端收到客户端的第一次挥手之后会回传一个ACK确认报文此时服务端的状态进入到CLOSE_AWAIT状态。由于ACK报文是没有重传机制的所以一旦服务端没有把ACK回传给客户端且接收到则由客户端发送方来触发超时重传机制。这也是一问一答式的必须有问有答才算一回合结束。▲图/ 第二次挥手超时重传机制客户端收到ACK报文则状态由FIN_WAIT_1变为FIN_WAIT_2的状态。这个状态需要等待服务端发送第三次挥手也就是服务端的FIN报文。这里客户端收到ACK进入到FIN_WAIT_2状态之后调用close关闭函数之后便无法再发送和接收数据所以这个FIN_WAIT_2状态也不会持续很长而 tcp_fin_timeout 控制了这个状态下连接的持续时长默认值是 60 秒。▲图/ close函数关闭机制意味着如果在60秒后还没有收到FIN报文客户端的连接就会直接关闭。但是如果客户端主动方关闭使用shutdown函数代替close函数关闭连接时指定了只关闭发送方而接收方并没有关闭那么主动关闭方还是可以接收数据的。服务端接收方还在处于接收状态就无法发送FIN报文那么客户端主动方就会一直处于FIN_WAIT_2状态你可能会想tcp_fin_timeout这个时间倒计时可以主动关闭状态。很遗憾tcp_fin_timeout这个参数只对close函数有用对shutdown函数无效并会处于一直等待中没有杀死这个线程甚至可能死等中。这是一个不到万不得已的下策。▲图/ shutdown函数关闭机制第三次挥手做了什么到了这里进入到第三次挥手。在上一轮服务端进入CLOSE_WAIT状态后进程主动调用close函数进入到内核内核会发送一个FIN报文同时进入LAST_ACK状态等待客户端返回ACK来确认连接关闭。▲图/ 第三次挥手超时重传机制这里如果迟迟收不到客户端返回的ACK报文则依然会触发重传机制重发次数仍然由tcp_orphan_retries 参数控制。第四次挥手做了什么服务端发送了FIN报文之后就进入到第四次挥手了。当客户端收到服务端的第三次挥手的FIN报文之后就会回传一个ACK报文也就是第四次挥手并且进入到TIME_WAIT 状态。TIME_WAIT状态根据操作系统的不同一般Linux系统是持续2MSL2倍的最大生存时间进入关闭状态。▲图/ 第四次挥手超时重传机制服务端若没有收到客户端发来的ACK报文则依然处于LAST_ACK状态。超时未接收到则客户端会触发超时重传FIN报文重发次数仍然由前面介绍过的 tcp_orphan_retries 参数控制。时代的眼泪你看这是我有始有终的机制对于我来说每一步都不是多余都是为了双方能够建立安全稳定的通道不会在错重复杂的通讯管道中将数据错误的传达。当然这些是我在连接和断开方向上的主要特点。我的主要功能不仅这些 重传、滑动窗口、流量控制、拥塞控制都是我的一套完整的高可用体系。在我和应用层HTTP组合已经有四十年左右在此期间我可以是撑起整个互联网的元老之一毫不夸张的自诩为互联网的血脉。但是也难挡时代带来的风霜我有一个死对手UDP这个将是我永远过不去的坎以前我从没觉得它能够赶超我甚至替代我它的好处就是快靠不靠谱我不说。但是随着时代的发展人们对于速度的要求越来越高人们不断地改良网络模型我的兄弟也在升级已经有了IPv6而与我患难与共的HTTP则是不断的从1.0优化到了3.0这个版本的出现彻底的让我感到emo因为http3.0版本已经使用我的死对头来替换了我他们将UDP的速度发挥起来并且对于安全连接和数据校验相关做了很好的控制。这也是我为什么要开始emo和吐槽了。 更多有趣内容请多关注
