UDP不能保证顺序,不能保证先来后到,任何数据包过了路由之后,路由爱怎么对他转发是路由的事情.但是TCP有顺序ID,而且要ACK后才继续说话,这种尴尬的事情就不会发生了.
UDP的话,你用最高速度给STM32发数据,比如1000Mbps,他只会忙死,而你不知道他已经丢包要死了.但是TCP的话,每听到一句话,要对方说,我收到了,下句话才说,速度就被控制住了,就算我CPU再慢,也不至于丢包.
实在没什么好办法说握手了.只能盗图.还有就是抓包工具分析.
第一次,SYN,就是客户端跟服务器说,我想连你.我带着一个Seq,参数是0.
第二次,SYN + ACK,好吧,你就连吧.为了表示我没听错,我ACK是你Seq的加1,我再做一个Seq,我设参数是0.
第三次,ACK,好的,我这就连.因为你给我的Seq是0,我为了表示我听到了,我ACK就是你Seq的加1,也就是ACK=1,连接上了.
那四次挥泪告别呢?
第一次,我发了个FIN + ACK,表示我要再见了,Seq是1,ACK是1.
第二次,他为了响应我,发了个ACK,表示,知道了,你要分开,ACK序号就是上一个Seq序号加1.
第三次,既然要分开了,我们痛快点,我也要跟你FIN + ACK,Seq带着1,ACK带着2.然后10.0.1.8(服务器)就断开连接了.
第四次,好了,我知道了,发了个ACK,是上一次Seq加1,并且我还新写了Seq.但是,这个数据服务器是收不到的,我们发完ACK后,等待2毫秒,发现服务器没ACK我,那么就服务器关了,那我也放心关了.
通信过程也是靠ACK和Seq来确保顺序和收到,我们知道这么一回事就行,暂时来说.
真要分析是另当别论.TCP包的格式也相当复杂很多.