hust_dxxxd的专栏

TCP中的TIME_WAIT状态原因主动关闭方需要确认被动关闭方最后是否会重发FIN：因为主动放发送的ACK可能会丢失。防止旧的（采用相同插口对）连接的数据干扰新的连接：这点要求其实只要达到MSL即可。 由于TIME_WAIT状态的存在，主动关闭方将不能立即重用处于2MSL期间的端口,被动关闭方没有影响。可以使用SO_REUSEADDR选项来强制重用端口，但是这解决不了TCP对处于2MSL等待

实战面试题：4月份腾讯在南京的面试（跪了），关于TCP/IP的部分： TCP四次握手，”在发fin后，如果没有收到ack会怎么样？“ 但是答的是会重发FIN。问“等多久重发呢？”，答好象是指数退避时间。“指数退避不是链路层的嘛？”，然后就下一个问题了。 现在想了想，应该是超时重传啊，也不清楚当时面试官想要的答案是什么。接下来就是关于“客户端发送最后一个ACK后，端口可以是否可以立即重用？”，答

TCP/IP问答TCP和UDP的区别？两者都是传输层协议，TCP（Transmission Control Protocal），名称反应了它最大的特征，就是对传输过程有很好的控制，即面向连接、可靠的、面向字节流的协议，它可以实现差错控制、流量和拥塞控制。UDP（User Datagram protocal），用户数据报协议，名字反应了它的一大特征，基于用户数据报。TCP的所谓面向字节流，是对TC

TCP的流量控制1. 利用滑动窗口实现流量控制    如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。    利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。    设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里

2.2 快重传和快恢复    如果发送方设置的超时计时器时限已到但还没有收到确认，那么很可能是网络出现了拥塞，致使报文段在网络中的某处被丢弃。这时，TCP马上把拥塞窗口 cwnd 减小到1，并执行慢开始算法，同时把慢开始门限值ssthresh减半。这是不使用快重传的情况。    快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到

主动关闭的Socket端会进入TIME_WAIT状态，并且持续2MSL时间长度，MSL就是maximum segment lifetime(最大分节生命期），这是一个IP数据包能在互联网上生存的最长时间，超过这个时间将在网络中消失。MSL在RFC 1122上建议是2分钟，而源自berkeley的TCP实现传统上使用30秒，因而，TIME_WAIT状态一般维持在1-4分钟。    TIME_WA

再叙TIME_WAIT发表于2013-12-31之所以起这样一个题目是因为很久以前我曾经写过一篇介绍TIME_WAIT的文章，不过当时基本属于浅尝辄止，并没深入说明问题的来龙去脉，碰巧这段时间反复被别人问到相关的问题，让我觉得有必要全面总结一下，以备不时之需。讨论前大家可以拿手头的服务器摸摸底，记住「ss」比「netstat」快：shell> ss -ant