这几天临近过年了，很多人都回去了，趁着闲着，把TCP/IP协议详解大概过了一过，有些以前似懂非懂的，现在貌似还是似懂非懂，不过至少比以前理解的好一点儿了，不过对于TCP的发包与回应之间的确认序号有点儿搞懵了，于是大概看了下，顺便在这里做了个笔记。
之前的工作大概都属于上层工作吧，至少在协议之上，各种操作系统的IO模型，倒是底层没怎么去看，只知道大概的三次握手啊之类的，还是得对底层有点儿了解才行。
首先在这里的ACK，指的是TCP头部设置了ACK Flag的回应包，用于发送确认序号，或者是握手包；
SEQ，指的是TCP头部的发送序号吧。
一开始简单的以为每一个TCP层的包，另一端收到后仅仅是序号+1，后来才发现我错了，是以字节数来计数的。
首先，ACK其实在回应确认包的时候才有意义，用于回应另一端自己这儿已经收到N序号的数据了，而SEQ在发包的时候有意义，用于表名该数据是N序号偏移的数据？这个解释好像也不太好，应该是N序号之后的数据。
当完成握手后，假定CS两端的SEQ序号都为1，那么当C端第一次发送数据(假定4字节)到S端的时候，C的TCP头部应该为S1A1，并且带着4字节的数据；
S端收到了数据后，会回应一个ACK，头部为S1A5，用于回应S端已经收到了4字节的数据了，下次再传的话，从4字节后开始传；
C端第二次开始往S端发4字节的数据，头部为S5A1，其中的S5表示C端是从4字节之后开始传的了，之前的4字节已经确认OK了，不用重传了（TCP有着重传与检测乱序的机制，还是要依赖于SEQ的，不然无法确认当前的发送的字节是属于另一端哪一部分的数据）；
S端收到了第二个包后，再次回应ACK，头部为S1A9，表明已经确认收到了C端的8字节的数据了；
S端开始给C端发送4字节的数据，则开始发包，头部为S1A9（其实ACK的标志位没有设置，这个A应该是没什么用的），而S端第一次给C端发送数据，所以S还是1，代表了发送的数据是S端第一次发送的数据，或者说曾经在此TCP会话上发送了0字节的数据；
C端收到了S端的包后，会回应ACK，头部为S9A5，S9代表了从C端已经传送了8字节的数据了，但是在ACK中，这个貌似也没啥用，而A5则表明了已经收到了服务器的4字节的数据了。
大概的通讯流程大概就是这样，简而言之，SEQ在发送数据的时候有实际的意义，表明发送的N字节的数据是属于该会话中哪一部分的数据，而ACK则是在确认收包的时候有意义，代表着另一端已经收到了该会话中N字节的数据了，这些都是TCP支持乱序重传以及发送失败重传的机制。
以前就有疑问，假设TCP会话中，A端发送了N字节给B端，B端迟迟没有回应，于是A端又发送了一次数据给B端，然而这时B端的回应包到了，那么B端不就是收到了2次数据吗？现在想想，其实B端根据A端数据包的SEQ，就可以知道自己已经收到过这部分数据了，所以不存在多次收发的问题，底层的东西想清楚，其实很多问题都可以迎刃而解。
不过自己对这块还是很生疏，希望在17年能够继续学习进步吧。
作者
