读《《图解TCP/IP》》有感

TCP/IP

近期几天读完《《图解TCP/IP》》，收获蛮多，记得上学时读stevens的《《TCP/IP具体解释》》时那是一个囫囵吞枣，没认真看也看不下去。等有时间再拜读下《《TCP/IP具体解释》》吧，预计能有不少共鸣。

如今认为。要想比較透彻理解TCP/IP，还得须要有server编程经验，学校应该同一时候开设《socket编程》》相关课程，最好同一个老师教，能够串讲，不然光理论不实战就是花架子，并且也不easy真正理解TCP/IP协议。

TCP/UDP一览

仅仅有较为透彻的理解了TCP/UDP才知道为啥TCP叫传输控制协议。UDP叫用户数据包协议。TCP在背后帮你做了非常多事，连接管理，保存时序，超时重发，拥塞控制。流控。通过mss自己主动帮你做分片，以降低传输途中路由器分片消耗(IPV6路由器是不会分片的)，这叫传输控制协议，突出“控制”二字。而UDP什么都不帮你做，不保证时序。不做超时重传，是须要上层协议来保证，也就是用户来写规则，这也是第一个U(user)的含义。同一时候UDP没有mss，所以一次性发送数据最好不要太多。以免分片导致性能损耗。

那UDP为什么叫用户数据包协议呢。说到数据包就得说说TCP和UDP的面向连接和无连接了。

我们知道TCP是面向连接的，而UDP是无连接的。这就直接导致了TCP会通过三次握手连接server，假设serverport不正确TCP是知道，但UDP不一样。压根不知道server段的情况。即使server不在线，client照样发送数据。

In [22]: import socket

In [23]: s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

In [24]: s.sendto("hello world",("127.0.0.1",9999))

Out[24]: 11

没有服务端。我们照样发送数据，sendto()照样返回。假设你之前不知道。这会让你大吃一惊，这也正说明了UDP不做数据包确认。

TCP传输的是流式数据，也就是说中间是没有分段的，这也就导致了我们常有的粘包问题，所以我们须要封包和解包，常见的都是字节长度+数据的方式，如websocket。也就是说我们接受一次，可能是对方多次发送后的数据集合，也可能是发送一次的部分数据，这都有可能，不能假设是哪种情况。这不经让我想起曾经上学时写的简单socketclient，server程序。都是一发一收。我们没封包解包不也正常吗？这就要说说Linux recv系统调用了。

int recv( SOCKET s, char FAR *buf, int len, int flags);

recv运行流程(来自网上)

1.recv等待s发送缓冲区数据发送完成，假设中途出现网络错误，recv函数返回SOCKET_ERROR

2.recv检查s的接受缓冲区。假设接受缓冲区没有数据或者

正在接受数据。那么recv一直等待，直到把数据接受完成。当接受完成后，recv会把s接受缓冲区的数据copy到buf中(缓冲区数据可能大于buf长度。所以须要多次调用recv。

recv仅仅是copy数据，真正接受数据是底层协议来完成的)

那这就好理解了，因为我们client一般是先send再recv，再发送完成之后recv会等待，并且我们数据量比較小，每次间隔比較大。所以有数据了，recv就返回了。当然这也是存在隐患的，发送数据大。一次recv可能接受不了。那就须要多次recv。这时就须要封包了，不然你怎么知道什么时候该返回。

就拿Http来说，服务端通过Content-Length和chunked编码来封包，让浏览器解析数据。

当然http1.0事实上Content-Length是非必须的，因为每次发送完数据后。服务端都会close，clientrecv会返回0，这时候也就知道数据结束了，也就是close作为了EOF标志。一帮下载都是通过这样的方式，所以也不会有粘包。

而UDP是不会出现粘包的，接收肯定能完整接收到发送的数据，世界瞬间清净了，这也是UDP**数据包**的概念，一个一个的数据包，接收的都是完整的数据包。

校验和

TCP/IP中校验和校验算法都几乎相同，也就是所谓的

反码求和

步骤例如以下

1.将校验和置为0

2.将数据转换为16字节整形，不足补零，求和(採用32位加法，将高16位和低16位相加，再将可能产生的进位与低16位相加)

3.和求反

最后发送者将校验和替换为求反的结果，将数据发给接受者，接受者忽略第一步採用相同算法。假设最后结果不为0，将丢弃该数据包。

手痒了一下。于是用golang模拟了下

//校验和算法

//对每16位(2字节)进行二进制反码求和,反码求和的意思是先对每16位求和。再将得到的和转为反码

func CheckSum(data []byte) uint16 {

    //padding 16

    all := len(data) / 2

    if all*2 < len(data) {

        all++

        data = append(data, 0)

    }

    u16 := (*[0xffff]uint16)(unsafe.Pointer(&data[0]))[:all]

    var sum uint32

    for _, u := range u16 {

        sum += uint32(u)

    }

    sum = (sum >> 16) + (sum & 0xffff) //把高位的进位，加到低八位

    sum += sum >> 16                   //前一步可能有进位

    return (uint16)(^sum)

}

func main() {

    check := make([]byte, 2)

    data := []byte("tcp/ip checksum test1")

    //首位作为校验和字段

    all := []byte(string(check) + string(data))

    sum := CheckSum(all)

    fmt.Println(all, sum)

    //校验和写入首位

    copy(all, (*[2]byte)(unsafe.Pointer(&sum))[:])

    fmt.Print(all, CheckSum(all))

}

结果:

[0 0 116 99 112 47 105 112 32 99 104 101 99 107 115 117 109 32 116 101 115 116 49] 22732

[204 88 116 99 112 47 105 112 32 99 104 101 99 107 115 117 109 32 116 101 115 116 49] 0

我们发现最后的确是0。说明我们算法没问题，至于为什么应该是0，小伙伴们想想就知道了。

TCP序列号与滑动窗体

以下说说TCP的seq,ack，在两方通信时seq開始是随机生成的，

假设A開始seq100,ack 1,发送数据size 100

1.A->B 初始随机seq 100,ack 1，发送数据10字节

2.B->A 初始睡觉seq200,告诉A下一个发送111。前面的数据都收到了,因为B仅仅是回应包 size 0

3.A->B A收到B的回应。看到ack为111。知道前面的10个自己都已经成功发送了。所以seq为111，发送1000个字节，并回应B下一个開始发送201

4.B->A ack为1000+111+1。告诉A下次从1112開始发送

仅仅要对方回应了ack。那么就代表ack之前的数据都已经成功接收了。这是对方就能够把自己缓冲区的相应数据给清空了，不然须要保存以待重传。因为每次都单项传输。吞吐量有点低，所以TCP引用了滑动窗体。也就是在没有明确收到ack之前能够连续发送w个包。w就是滑动窗体的大小。因为引用了滑动窗体。有些ack丢失也没有关系。仅仅要收到了兴许的ack确认就代表之前的数据都已经成功接收了。

CSMA/CD

通信专业的对CSMA/CD肯定都不陌生。我发现老师特别喜欢说这玩意，但我曾经始终不明确这玩意有啥用？事实上CSMA/CD是用于共享网络的，也就是通过hub或同轴电缆等连接的总线型或星型拓扑结构。因为这东西我们基本都没见过(过时了)，因为须要冲突检查所以是半双工通信。当交换机出来时，CSMA/CD就被淘汰了。通过交换机的port转发实现了全双工通信。不知道是当初老师的问题还是我太弱，如今才明确应用场景。

如今的无线也是半双工的。是CSMA/CD的改良版，叫CSMA/CA。