之前我在「实战！我用“大白鲨”让你看见 TCP」这篇文章里做了 TCP 三次握手的三个实验：
TCP重传机制主要是为了防止网路包丢弃，重传的工作方式主要借助TCP头部中的序列号和确认号来决定是否重传，重传的触发方式主要由以下几种：
为了让大家更容易「看得见」 TCP，我搭建不少测试环境，并且数据包抓很多次，花费了不少时间，才抓到比较容易分析的数据包。
TCP协议仅定义框架，也就是发送端和接收端需要遵循的“规则”。TCP协议的实现经过多年的改进，有了多个不同的版本。比较重要的有Tahoe、Reno、NewReno、SACK、Vegas等，有些已经成为了影响广泛的RFC文档，有些则成为了Unix/Linux操作系统的标准选项。
在设计架构或涉及网络时，我们都知道网络是不可靠的，可能会发生超时、断开连接、网络分区等各种问题。这些问题对于数据传输的可靠性和稳定性产生了很大的挑战。为了解决这些问题，各个组织都设立了专门的网络部门，致力于研究和解决网络问题。
这一下，大家总算停止了灌水（这群人都不用上班的，天天划水摸鱼），开始讨论起这个问题来。
TCP协议是一个相当复杂的协议，其实现依赖于多个定时器的实现。在TCP套接字的初始化函数tcp_v4_init_sock中，会调用tcp_init_xmit_timers初始化TCP的各个定时器。
收到一位读者的私信，说字节面试有这么一个问题：服务端挂了，客户端的 TCP 连接会发生什么？
前两天，我在微博上推荐了一篇朝花夕拾的文章：The story of one latency spike，文章中介绍了 cloudflare 工程师如何一步一步 debug 网络延迟问题，细细读来受益良多，不过我并不打算详细介绍那篇文章的细枝末节， 本文只摘录一个点：
前些日子，在分享网络编程知识文章的时候，有个网友私信给我留言了一条“能不能写一篇关于 TCP 滑动窗口原理的文章”。
可以看到，这些问题都是关于 TCP 是如何处理这些异常场景的，我们在学 TCP 连接建立和断开的时候，总是以为这些过程能如期完成。
之前写过 TCP 三次握手和四次挥手过程中，途中某一步的报文丢失会发生什么的文章。
机器一般过质保之后，就会因为各种各样的问题而宕机。而这一次的宕机，让笔者观察到了平常观察不到的tcp在对端宕机情况下的行为。经过详细跟踪分析原因之后，发现可以通过调整内核tcp参数来减少宕机造成的影响。
最近花了些时间在学习TCP/IP协议上，首要原因是由于本人长期以来对TCP/IP的认识就只限于三次握手四次分手上，所以希望深入了解一下。再者，TCP/IP和Linux系统层级的很多设计都可以用于中间件系统架构上，比如说TCP 拥塞控制算法也可以用于以响应时间来限流的中间件。更深一层，像TCP/IP协议这种基础知识和原理性的技术，都是经过长时间的考验的，都是前人智慧的结晶，可以给大家很多启示和帮助。
最近花了些时间在学习TCP/IP协议上，首要原因是由于本人长期以来对TCP/IP的认识就只限于三次握手四次分手上，所以希望深入了解一下。再者，TCP/IP和Linux系统层级的很多设计都可以用于中间件系统架构上，比如说TCP 拥塞控制算法也可以用在以响应时间来限流的中间件上。更深一层，像TCP/IP协议这种基础知识和原理性的技术，都是经过长时间的考验的，都是前人智慧的结晶，可以给大家很多启示和帮助。
网络编程中超时时间是一个重要但又容易被忽略的问题,对其的设置需要仔细斟酌。在经历了数次物理机宕机之后,笔者详细的考察了在网络编程(tcp)中的各种超时设置，于是就有了本篇博文。本文大部分讨论的是socket设置为block的情况,即setNonblock(false)，仅在最后提及了nonblock socket(本文基于linux 2.6.32-431内核)。
TCP是一个巨复杂的协议，因为他要解决很多问题，而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程，但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节，我还是推荐你去看W.Richard Stevens的《TCP/IP 详解 卷1：协议》（当然，你也可以去读一下RFC793以及后面N多的RFC）。另外，本文我会使用英文术语，这样方便你通过这些英文关键词来查找相关的技术文档。 之所以想写这篇文章，目的有三个， 一个是想锻炼一下自己是否可以用简单的篇幅把这么复杂的TCP协议描清
说到TCP协议，对于从事即时通讯/IM这方面应用的开发者们来说，再熟悉不过了。随着对TCP理解的越来越深入，很多曾今碰到过但没时间深入探究的TCP技术概念或疑问，现在是时候回头来恶补一下了。
在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。
而且，这个超时时间在不同的网络的情况下，根本没有办法设置一个死的值。只能动态地设置。 为了动态地设置，TCP引入了RTT——Round Trip Time，也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间，从而可以方便地设置Timeout——RTO（Retransmission TimeOut），以让我们的重传机制更高效。 听起来似乎很简单，好像就是在发送端发包时记下t0，然后接收端再把这个ack回来时再记一个t1，于是RTT = t1 – t0。没那么简单，这只是一个采样，不能代表普遍情况。
TCP/IP深入学习 作为互联网时代伟大发明的TCP/IP技术可以说对当今时代产生了深刻的影响。经过近一个月的学习摸索，基本清楚了TCP/IP的面貌。由于TCP/IP在OS中位于内核态，很多细节其实用
很早之前写了这篇文章：你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗？看完图解就不愁了
这篇文章我想由浅到深地过一遍 TCP，不是生硬的搬出各个知识点，从问题入手，然后从发展、演进的角度来看 TCP。
前一篇「硬不硬你说了算！近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题」得到了很多读者的认可，在此特别感谢你们的认可，大家都暖暖的。
这个属于 TCP 异常断开连接的场景，这部分内容在我的「图解网络」还没有详细介绍过，这次就乘着这次机会补一补。
这是TCP/IP协议栈系列的第二篇文章，之前的一篇理解TCP/IP协议栈之HTTP2.0感兴趣可以看下，今天一起来学习下一个热点问题。
这次分享是腾讯后端面经，面试接近 1 小时，问了非常多的问题，涵盖Linux、数据库、C++、操作系统、计算机网络。
Linux作为一个强大的操作系统，提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中，笔者积累了一些在内网环境应该进行调优的参数。在此分享出来，希望对大家有所帮助。
上述表述的信息还是比较少的，我们在linux服务器上抓取的包一般会保存为pcap文件，然后导出到本地利用WireShark工具进行分析。
前言 说到TCP协议，相信大家都比较熟悉了，对于TCP协议总能说个一二三来，但是TCP协议又是一个非常复杂的协议，其中有不少细节点让人头疼点。本文就是来说说这些头疼点的，浅谈一些TCP的疑难杂症。那么从哪说起呢？当然是从三次握手和四次挥手说起啦，可能大家都知道TCP是三次交互完成连接的建立，四次交互来断开一个连接，那为什么是三次握手和四次挥手呢？反过来不行吗？ 疑症 1 ：TCP 的三次握手、四次挥手 下面两图大家再熟悉不过了，TCP的三次握手和四次挥手见下面左边的”TCP建立连接”、”TCP数据传送
我本来只想写一个篇幅的文章的，但是TCP真TMD的复杂，比C++复杂多了，这30多年来，各种优化变种争论和修改。所以，写着写着就发现只有砍成两篇。
本文主要介绍了在Linux系统中，如何通过配置TCP参数来优化网络性能。主要包括了TCP的四次挥手释放连接、TCP的慢启动和快速恢复、TCP的保活机制以及TCP的延迟应答机制等方面的内容。通过这些优化措施，可以大大提高Linux网络性能，减少网络拥堵和丢包现象，提高整体的网络吞吐量和连接的稳定性。
作者：engleliu，腾讯 PCG 开发工程师 本文主要介绍 TCP 拥塞控制算法，内容多来自网上各个大佬的博客及《TCP/IP 详解》一书，在此基础上进行梳理总结，与大家分享。因水平有限，内容多有不足之处， 敬请谅解。 一、TCP 首部格式 在了解 TCP 的拥塞控制之前，先来看看 TCP 的首部格式和一些基本概念。 TCP 头部标准长度是 20 字节。包含源端口、目的端口、序列号、确认号、数据偏移、保留位、控制位、窗口大小、校验和、紧急指针、选项等。 TCP 首部格式 1.1 数据偏移（D
在后端接口性能指标中一类重要的指标就是接口耗时。具体包括平均响应时间 TP90、TP99 耗时值等。这些值越低越好，一般来说是几毫秒，或者是几十毫秒。如果响应时间一旦过长，比如超过了 1 秒，在用户侧就能感觉到非常明显的卡顿。如果长此以往，用户可能就直接用脚投票，卸载我们的 App 了。
作者：morganhuang，腾讯 IEG 后台开发工程师 说到 TCP 协议，相信大家都比较熟悉了，对于 TCP 协议总能说个一二三来，但是 TCP 协议又是一个非常复杂的协议，其中有不少细节点让人头疼点。本文就是来说说这些头疼点的，浅谈一些 TCP 的疑难杂症。那么从哪说起呢？当然是从三次握手和四次挥手说起啦，可能大家都知道 TCP 是三次交互完成连接的建立，四次交互来断开一个连接，那为什么是三次握手和四次挥手呢？反过来不行吗？ 疑症（1）TCP 的三次握手、四次挥手 下面两图大家再熟悉不过了，
TCP是一个面向连接的协议。无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。
对于云上的用户来说，业务日志里面报超时问题处理起来往往比价棘手，因为1) 问题点可能在云基础设施层，也有可能在业务软件层，需要排查的范围非常广；2) 这类问题往往是不可复现问题，抓到现场比较难。在本文里就分析下如何来分辨和排查这类问题的根本原因。
小到基于应用层做网络开发，大到生活中无处不在的网络。我们在享受这个便利的时候，没有人会关心它如此牢固的底层基石是如何搭建的。而这些基石中很重要的一环就是tcp协议。翻看一下“三次握手”和“四次挥手”，本以为这就是tcp了，其实不然。它仅仅解决了连接和关闭的问题，传输的问题才是tcp协议更重要，更难，更复杂的问题。回头看tcp协议的原理，会发现它为了承诺上层数据传输的“可靠”，不知要应对多少网络中复杂多变的情况。简单直白列举一下：
计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。
TCP作为一种可靠传输控制协议，其核心思想既要保证数据可靠传输，又要提高传输的效率，而用三次恰恰可以满足以上两方面的需求！
我第一次写 TCP 文章是这篇：硬不硬你说了算！近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题
我们先来看看 TCP 头的格式，标注颜色的表示与本文关联比较大的字段，其他字段不做详细阐述。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
