第五章 Internet协议
ip提供了一种尽力而为、无连接的数据包交付服务。每个数据报独立于其他数据报被处理。
ipv6头部长度固定为40字节，在头部中没有可选的flag，ipv6和ipv4中只有起始4bit是相同含义 版本号。同时ipv6头部没有校验和字段，虽然ipv6头部错误会导致错误的交付，但是目前的环境下，几乎不会发生位错误，所以将校验的任务交给了上层协议。
第十二章 TCP：传输控制协议（初步）
ARQ和重传
直接处理分组丢失或者比特查错的方法：一直重发直到本分组被正常接收
- 接收方是否接收到了分组？
- 接收方接收到的是不是和发送方发送的一样？
ACK
- 发送方应该等待一个ACK多长时间？
- ACK丢失了怎么办？
- 分组被接收到了，但是有错怎么办？
允许多个分组同时进入网络而不是发送一次确认一次存在的问题
- 什么时候注入一个分组？
- 注入多少个分组？
- 等待ACK的时候如何维持计数器？保存未被确认的分组防止重传
- 需要能够区分出哪些分组收到了哪些没有收到，而且能够组装乱序的分组
- 如果接收方的接收速度慢怎么办？
滑动窗口 解决了上面的问题
发送方
- 记录着哪些分组可以被释放
- 哪些分组已经发送正在等待ACK
- 哪些分组还待发送
接收方
- 哪些分组已经被接收和确认
- 哪些分组是下一步期待的
变量窗口：流量控制和拥塞控制 解决了窗口大小确定和接收方接收不过来的问题
流量控制 接收方跟不上的时候通过此迫使发送方慢下来
窗口通告（窗口更新）：跟ACK在一次 调整窗口大小
拥塞控制：流量控制应对的是接收端和发送端问题，拥塞控制则是之间的网络问题
TCP不会自动插入记录标志或者消息边界，不会解读字节流中的内容，对于内容的解读交给了端点的应用程序。
TCP的包头没有包长度字段，而UDP却有
SYN会消耗一个序列号 尽管没有包体 由于消耗了序列号，丢失会被重传
ACK则不会消耗序列号
TCP可以被描述为带累计正向确认的滑动窗口协议
源端口 目的端口 源IP 目的IP唯一的标识了一条连接。（相对传统使用UID来标识的协议，这里使用了四个字段才进行标识）
第十三章 TCP连接管理
三次握手不仅让通信双方了解到了
- 一个连接正在建立
- 利用数据包的选项传递特殊的信息
- 交换初始序列号，端口号
第三次握手丢失后
被动连接方在超时后会重发SYN+ACK，如果超过指定次数没有回应 则关闭连接
主动连接方connect会在第二次握手成功后状态就转变为established，这时如果向被动连接方发送数据会导致RST
四次挥手连接关闭
- 主动关闭方，希望对方看到自己当前的seq，以及FIN包还会包含对对方最近一次数据的ACK
- 被动方的上层应用程序会被告知连接另一端提出了关闭连接的请求。
- 如果FIN丢失，发送方会重新传输直到收到确认的ACK
shutdown和close的区别
- close会立刻关闭此文件描述符， 无法再读写文件描述符
- shutdown还能根据传入的参数，一般是关闭写，这样还能继续读取残留的数据。
- 多进程共享文件描述符的时候，close只会影响本进程，而shutdown会影响全部进程