'''
作者:lg
日期:2019/11/30
文件描述:
缺陷：
'''

# 建立连接过程:
# 三次握手
# 其实本质上还是四次握手,
# 第一次,A->B:我可以连接你吗?
# 第二次,B->A:可以,那我可以连接你吗?
# 第三次,A-B:可以

# 第二次把两个步骤合并到一起了

# 数据传输过程
# 每一次给对方发完消息后,对方都必须回一个消息,确保双方都知道这个消息收发成功


# 四次挥手过程
# 全双工,相当于耳朵和嘴巴


# TCP连接
# 双向连接,效率低,每次我给你发消息你都得回我一次


# tcp的连接始终只有一对,一个服务器对应一个客户端
# udp可以有多个连接

# tcp建立连接后,可以由服务端或者客户端先发消息
# udp必须客户端来连接我,并且发内容来了后,服务端才能发消息,因为udp都不知道对面是谁


# udp的server不需要进行监听也不需要建立连接
# 在启动服务之后,直播被动的等待客户端发送消息过来
# 客户端发送消息的同时还会把自己的地址带上
# 服务端消息回复的时候,不仅回复消息,还有把对方的地址填上,才知道要发往哪里

# udp的一个服务端与多个客户端连接时
# 由于服务端只有一个线程,可能会阻塞在某个地方,所有不能实时与对个客户端通信


# 黏包现象:
# tcp会黏包,但是完整
# udp不会黏包,但是超过一定程度就不完整了,不可靠

# 黏包分析:
# 对于用户,可能是发了两次消息
# 用户发的消息先是存到缓存了,对于内核,内核感知到缓存里的这两个消息又短有小,就合并到一起了
# 如果第一次recive没有把缓存里的内容全部接受,第二次recive就会把剩余的缓存内容接收到!!!!!

# 黏包本质原因:recv!!!!
# recv会根据要接受的内容大小来从'本地缓存'里收取来自发送端的内容
# 如果recv的数值比发送的内容大,那么就会等发送的内容足够大后,才会取缓存里的内容
# 如果recv的数值比发送的内容小,那么会直接取数值的内容,剩下来的下次recv再去取

# 一发一收一般不出现黏包的情况,多次收发就会出现黏包现象
# 第一次接受数字的时候,也不知道对面到底会发送多少个字节,所有接受完需要给对面回复一下,防止发送端出现黏包
