新人学习，如有错误请见谅和指正。如果大家参考，请多找资料和实验进行比对研究。谢谢

iphdr->tot_len

总长度字段(16位)是指整个IP数据报的长度,以字节为单位。利用首部长度字段和总长度字段,就可以知道 IP数据报中数据内容的起始位置和长度。由于该字段长16比特,所以IP数据报最长可达65535字节

总长度字段是IP首部中必要的内容,因为一些数据链路(如以太网)需要填充一些数据以达到最小长度。尽管以太网的最小帧长为46字节,但是IP数据可能会更短。如果没有总长度字段,那么IP层就不知道46字节中有多少是IP数据报的内容。

tcphdr->doff
TCP头长度，指明了在TCP头部包含多少个32位的字。此信息是必须的，因为options域的长度是可变的，所以整个TCP头部的长度也是变化的。从技术上讲，这个域实际上指明了数据部分在段内部的其起始地址(以32位字作为单位进行计量)，因为这个数值正好是按字为单位的TCP头部的长度，所以，二者的效果是等同的

由这两个参数来规定tcp内数据包的大小？但是以太网的填充字段（Padding）怎么办。

TCP数据包的大小是很大的，但是如果超过MTU就需要分片发送数据包。所以在syn攻击里应尽可能采用单包发送，提高效率。【详见附1】

test1:
操作：修改ip.tot_len字段（加20）并且给发送的总包加上相应字段内存
结果：失败了，收到数据包大小为74（54+20），尾部的填充6Byte不见了，并且协议解析为NBSS
【通过搜索相关知识，了解到eth.padding的6Byte是以太网的填充字段，为了让数据包对齐32bits进行传输】
【通过相关查询，了解到NBSS是139端口（我攻击的端口）提供的共享打印机服务，那是不是我换个端口就好了？】

test2:
操作：./awl -i 192.168.45.1 -p 1399 -I 192.168.45.129 -t 20【自己改的syn攻击程序，-i是对方ip，-I是自己ip，-p是对方端口，其他未设定参数（mac、port）默认采用随机】
结果：成功了，收到数据包大小为74，Data字段为0填充。看来这个真的是跟端口有关系呢。。

test3:
操作：./awl -i 192.168.45.1 -p 8080 -I 192.168.45.129 -m 00:50:56:c0:00:08 -n 1【打开了主机的apache，端口8080开启，指定对象的mac和随机的源ip位】
结果：成功造成攻击，服务器收到syn后进行arp请求查找源ip的mac地址，保持SYN_RECEIVE状态(回复syn+ack后由于对方主机的响应端口并没有开启的程序，收到ICMP的回执并继续进行重试)，如下图。当停止攻击后，保持的状态迅速被删掉。（增加包大小成功）
图示：

test4:
操作：同3，把数据包降为无data的包，并且随机4个ip进行攻击
结果：apache死掉了。。所以我也不知道速度，需要重启一下- -不过参见以前的记录，六个进程同时开启情况下有64Kpackages/s，在单包60Byte情况下占用带宽30Mbits/s

【附1:MTU大小】
以太网EthernetII最大的数据帧是1518Bytes，刨去以太网帧的帧头14Bytes和帧尾CRC校验部分4Bytes，那么剩下承载上层协议的Data域最大就只有1500Bytes，这个值我们就把它称之为MTU。

UDP 包的大小就应该是 1500 - IP头(20) - UDP头(8) = 1472(BYTES)
TCP 包的大小就应该是 1500 - IP头(20) - TCP头(20) = 1460 (BYTES)

当发送包大小大于MTU时，就会再ip层做分包处理。如果使用UDP协议，当IP层组包发生错误，那么包就会被丢弃。接收方无法重组数据报，将导致丢弃整个IP数据报。UDP不保证可靠传输；但是TCP发生组包错误时，该包会被重传，保证可靠传输。