本实验通过SSH远程登录server,然后使用Wireshark抓包分析。





开头的三次握手已经省略。关于序号的交互过程。须要记住一点:TCP首部中的确认序号表示已成功收到字节,但还不包括确认序号所指的字节。希望下一次能收到确认序号所指的字节。
当在远程登录软件上键入命令时,client便開始了数据的发送。TCP头例如以下:

初始化序列号ISN = 1,这个序列号是client对发送数据的一个标记,以1作为起始值。依据SSH包长度计算下一次将会发送的起始序号为65。确认序号为1表示我希望下次收到起始序号为1的TCP包。
server端返回的TCP头例如以下:
.png)
client想要序号1,那server就发送序号1。所以server发送的TCP包起始序号为1。同一时候。server又希望下一次收到起始序号为65的包,这和client下一次会发送起始序号为65的包全然吻合。
client发送的TCP头例如以下:
.png)
server要序号65,那我client这边就发送65。
同一时候我希望下一次收到序号65。
server的TCP头例如以下:
.png)
server果然又满足client的要求返回65。
同一时候希望获得序号129。
client和server两端重复进行这种过程直至连接中断(见文章“四次握手终止连接”)。每个TCP包头都在满足对方的需求同一时候希望对方会满足自己的需求...
參考:
《TCP/IP具体解释》 P172、P175.