网络编程（一）

一、数据封包和拆包的过程

也有的地方写的是 64-1518 ，这个是因为把以太网头(14字节)和以太网尾(4字节)也算了进来。1500是最大传输单元 MTU，linux系统默认都是 1500，使用ifconfig命令 看 mtu后面对应的数值

二、链路层

以太网头(MAC头)

目的mac地址：接收方的mac地址 --我的windows的mac地址
源mac地址：发送方的mac地址 --我的Ubuntu的mac地址
类型：指定了后面使用的协议的类型
0800 IP协议
0806 ARP协议
8035 RARP协议

三、网络层

IP头

版本：IP协议协议的版本 4 表示IPV4
首部长度：（由于首部长度只有4个bit为能表示最大数 1111 是 15，但是ip头是20个字节
所以此处使用的4倍的单位， 此处是5 就表示 20了）
总长度：IP头+TCP头+用户数的长度
对于我们的例子来说: 20+20+128 == 168
生存时间TTL：
表明是数据包在网络中的寿命，即为“跳数限制”，
由发出数据包的源点设置这个字段。
路由器在转发数据之前就把TTL值减一，
当TTL值减为零时，就丢弃这个数据包。
通常设置为 32、64、128
协议类型：表明后面使用的协议
ICMP(1),IGMP(2),TCP(6),UDP(17)
源IP地址：发送方的IP地址 Ubuntu的IP地址
目的IP地址：接收方的IP地址 windows的IP地址

四、传输层

TCP头

源端口号：Ubuntu的端口号 操作系统指定的 随机值
目的端口号：windows服务器的端口号 6789
序列号：seq
确认号：ack
头部长度：TCP头的长度 也是 4倍的单位

五、应用层

六、TCP三次握手、四次挥手

三次握手

三次握手是由客户端主动发起的，发生在建立连接的过程中。发生在服务器的accept函数(listen函数)和客户端的connect函数之间。
三次握手就为了保证通信的双方都知道对方收发数据的能力没问题。同时，也是同步序列号的过程。

四次挥手

四次挥手是由主动关闭方发起的(一般都是客户端发起)
四次挥手发生在连接断开的过程中

七、TCP/UDP补充

TCP：
1、TCP网络编程中可以使用 read/write send/recv sendto/recvfrom 来收发数据。
2、TCP的服务器默认的是一个循环服务器，没法同时处理多个客户端的请求，原因是tcp的服务器有两个阻塞函数 accept 和 recv，两个函数之间相互会有影响。可以使用 多进程 多线程 IO多路复用 来解决。

UDP：
1、UDP是无连接的，但是也可以双向的收发数据
因为UDP使用的是 sendto/recvfrom 来收发数据，sendto时可以指定接收方的信息。
sendto函数相当于 send函数和 connect函数的二合一
recvfrom函数相当于 recv函数和 accept函数的二合一
2、UDP中客户端也可以使用 connect 函数先将自己的网络信息结构体发给服务器，
然后就可以使用 send 和 recv 收发数据了。
3、如果UDP服务器端的recvfrom函数的后两个参数设置成 NULL了，那么接收数据是没有问题的，
但是就没法给发送方回信了，因为sendto的后两个参数没法填写。
4、UDP服务器默认的就是一个并发服务器，因为只有一个阻塞的函数 recvfrom。

八、TFTP协议

**TFTP：**简单文件传送协议
最初用于引导无盘系统，被设计用来传输小文件
**特点：**基于UDP协议实现、不进行用户有效性认证
数据传输模式：
octet：二进制模式
netascii：文本模式
mail：已经不再支持

TFTP通信过程

TFTP通信过程总结（无选项）
1、服务器在69号端口等待客户端的请求
2、服务器若批准此请求,则使用临时端口与客户端进行通信
3、每个数据包的编号都有变化（从1开始）
4、每个数据包都要得到ACK的确认如果出现超时,则需要重新发送最后的包（数据或ACK）
5、数据的长度以512Byte传输
6、小于512Byte的数据意味着传输结束

TFTP协议分析

错误码：
0 未定义,参见错误信息
1 File not found.
2 Access violation.
3 Disk full or allocation exceeded.
4 illegal TFTP operation.
5 Unknown transfer ID.
6 File already exists.
7 No such user.
8 Unsupported option(s) requested.