协议再探

0x01 原因

回顾协议时我又忘了，拿tcp来讲，tcp可靠，可靠在哪里，我依稀的记忆是，有一些协商的字段比如，seq、ack、滑动窗口;比如udp为什么无序等等；哎，这次再记录下来吧，遗忘是常态，熟能生巧

tcp协议

wireshark抓包wlan，我可以用kali构造一个tcp包发送，但现在的话，用nc先看看

#windows
nc.exe -l -p 1234
#kali
nc.exe ip 1234 #并发送whoami信息

三次握手

tcp的三次握手回顾一下：

A(kali)连B(win)，A->B,B->A,A->B

A->B：发送一个请求包

B->A：发送一个响应包和一个请求包

A->B：发送一个响应包

配合wireshark的话

A->B：seq number即序列号为0；Syn置为1

B->A：序列号初始为0，Ack+Syn均置为1，且返回包包含Ack=1

A->B：序列号为1，返回Ack=1

下面开始发送数据，kali发送whoami

A-B：发送字节数7，Seq=1

B->A：返回Ack=8

kali再发送一个ipconfig

A->B：发送字节数9，Seq=8

B->A：返回Ack=17

四次挥手

win退出的话，发送的是

要发起的那个(kali)主动退出

有感而发，怎么先炽热的却先变冷了？

额外

TCP Out_of_Order：一般来说是网络拥塞，导致顺序包抵达时间不同，延时太长，或者包丢失，需要重新组合数据单元

TCP Retransmission：超时引发的数据重传

TCP dup ack XXX#X原因分析：就是重复应答#前的表示报文到哪个序号丢失，#后面的是表示第几次丢失

UDP就不一样了，没这么啰嗦，行就是行，不行就是不行，数据它发了，收不收就不是它的事了

UDP

对于udp的包呢，我发了，但主机wireshark抓不到

import socket
import traceback
# 1.创建一个udp套接字
try:
    udp_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 2.准备接收方的地址
	udp_socket.sendto("hello".encode("utf-8"),("192.168.1.142",1234))

# 3.关闭套接字
	udp_socket.close()
except Exception as e:
    print(traceback.format_exc())

用nc.exe，也抓不到

(哦，对不起，wireshark过滤用udp.port而不是tcp.port)

结论

所以可以知道，tcp的可靠，是靠Seq字段和Ack字段来的

三次握手之后，发信息的一方，一定会收到另一方的一个返回包；

而且Seq不断递增的变化，保证了有序

但是UDP呢，就一个长度，发出去也没回应，也没有顺序性(对，因为每个udp包之间的是独立无关的)

用代码的话，就算服务端没有开udp端口，kali这边数据可以照发不误的，只不过会显示目标不可达(端口不可达)

但是tcp的话，不开tcp端口，数据都发不出去的

（双方是都是可以发消息的，我只是截图了单向的）

https://whowin.gitee.io/post/blog/network/0005-send-udp-via-linux-cli/

经典问题

1.好，两次握手、四次握手为什么不行？

这里要深究的话，其实是要看看为什么是三次握手？即三次握手的目的是什么？

从上图中可以明显看到：

1.Seq序列号保持初始同步

2.双方既能接也能发

3.避免重复历史连接

好，两次握手的弊端就出现了：

1.我能接，你能接吗？那，老师，我能发，你能发吗？

2.Seq初始序列号同步问题

四次握手呢？

既然三次握手就能搞定的事情，第四次握手，肯定牵扯到发送和接收，这是一个等待过程，白白消耗资源

2.我三次挥手请战！

看一下四次挥手在干什么

A->B：FIN，我不发东西啦

B->A：ACK，好的

B->A：FIN，我不发东西啦

A->：好的

这里和前面的握手中的SYN总结一下

SYN是有双向性质的，而FIN只是单方面结束关系，可以说是单向性；

FIN，只是说不再发数据了，但不代表它不能处理数据，即没有要求对方也不发数据；

像第三次挥手存在的一种可能就是这样，你不发是吧？那我发！

这里其实也解释了，为什么二三不能像握手时合并一样；

握手就手拉手；挥手，各回各的手

https://cloud.tencent.com/developer/article/2169717

ICMP

kali进行ping命令，wireshark抓到了16个

可以理解为它在IP层和传输层之间，硬要说，那也是在网络层

它这里有意思的地方是，对于一次ping命令来讲，它发了四个包，前两个是发起方，后两个是目标方。

而且第一个包永远是无回应的，好像只是为了确认能否到达；

这里停会儿，以后再看看，还是要多实践，只记是记不住

关于localhost和127.0.0.1

之前在哪里读过，有一个区别是后者是走网卡的

电脑一天没网了，刚好去实验一下

分别ping下127.0.0.1和localhost；同时wireshark捕获回环流量

ping localhost给了一个ipv6地址，优先于ipv4

除此之外，关于127.0.0.1的部分，不止于此，127.0.0.2/127.1.1.1等等都可以

这个时候断网了，明明wifi连接上，但没信号

ping 自己ip时依然有效；我断开wifi，保持无连接状态，上述ip依然有效

这个时候去连接上wifi，虽然没信号，wireshark抓包wlan；

ping 192.168.1.x时，过滤为icmp，没抓到（但是在回环流量中出现）；

但是ping 192.168.1.1时，抓到了

这里可以认为127.0.0.1“等价于”自己的wlan分配的ip，毕竟它们都出现在了回环流量里

localhost为什么没有出现在lo口，但是成功发送出去，这应该是一种更底层的协议，抓不到

当用小皮搭建一个网站后

127.0.0.1:81访问不谈

localhost:81是可以在回环流量中抓到的，去IP层看看，ipv6版本，地址均为**::1**

总结

0x01.ping命令时wlan分配的本机ip以及127.x.x.x存在于回环流量中，经过回环网卡；而localhost不经过该网卡

那经过哪里呢？

0x02.断网时，wlan监听依然有不停的数据包发送，应该是和运营商服务器在进行连接

它都进行ARP广播了，消息内容为Who has 192.168.1.1? Tell 192.168.1.x，后面有一条说这个ip在哪个MAC地址

同时，它也在发送几个TCP/UDP/TLS请求，我用的移动路由器，它的目的IP都是广东、天津、上海这些移动，嘶，怎么还有一条美国的IP、韩国IP也有？