趣谈网络协议笔记-二(第十三讲)

趣谈网络协议笔记-二(第十三讲)

套接字Socket:Talk is cheap, show me the code


前言

这只是笔记,是为了整理刘超大神的极客时间专栏的只是而存在的!

经常会在网络上看到甚至CSDN上看到这类文章,什么人工智能兴起,程序员都将集体丢掉饭碗,然后推荐人工智能课程,我感觉真的很搞笑!首先,先不说人工智能兴起,对程序员的饭碗会不会有影响,我真的为写这种文章的人的不要脸程度感到惊讶,你为了挣钱真的什么东西都不要了,和那些不要脸的培训机构一样,“不要让孩子输在起跑线上”!人工智能和程序员饭碗的联系,我之后有机会说说自己的幻想。

就算人工智能的兴起会让一部分人的饭碗受到影响,那也一定是首先会让你们这种社会的害虫,除了蛊惑大众,引发恐慌,不要脸面之外一无是处的人丢掉生计!
以上,与君共勉!

好了,开始今天的整理。


正文

BBR

上一节说到了BBR,但是并没有实际了解过具体是怎么操作的,但是就目前的情况而言,我只需要了解BBR是TCP的拥塞控制+延迟监控的结果即可。

这节其实相对之前的章节其实复杂的多,主要的原因是加入了一些linux的进程,线程的具体操作以及引入了一些数据结构。这其实在一定程度上也增加了我归纳的难度。当然作为归纳的角度所做的笔记,我是不会将我没有理解的部分强行加入自己的笔记中,就像盖一栋楼一样,你有可能会把自己不清楚的材料填充进楼层的建材里吗?

Socket程序基于TCP/UDP传输层协议的。通过Socket,就能搭建起客户端和服务器之间的沟通桥梁,实现基本的交互。遥想当年,我大学期间所编的第一个网络应用就是基于Socket的,虽然是Java的,但是加上了哈弗曼树的算法。虽然是一个小作品,当时真的很得意。

既然是基于传输层协议的程序,那就必须制定一些下层的规则,即IPv4还是IPv6(分别设置为AF_INET和AF_INET6),基于的时TCP协议还是UDP协议(SOCK_STREAM还是SOCK_DGRAM,即socket基于流还是数据报

既然明说了,是需要指定是流还是数据报,那么这两者在实际传输的层面一定是存在着明显的区别。指定IP的区别,那个只是基数差别的问题,与实际传输方式无关。

当SOCKET基于TCP协议

[image:1850CB20-8837-44F6-80A6-90F71B48A94C-301-0000544627512E7F/77d5eeb659d5347874bda5e8f711f692.jpg]

之前已经说过了,SOCKET进行传输的时候需要指定网络层协议和传输层协议,当然就需要将其绑定在一个ip+端口。对于TCP协议,因为TCP协议的目的就是为了尽可能地确保数据传输的可靠性,所以SOCKET的连接过程也相对复杂。

首先服务器会将创建一个SOCKET,通过调用bind方法将SOCKET绑定到一个(或多个)ip和端口。当服务端有了ip和端口,此时就可以通过调用listen函数进行监听,在TCP的状态图中,有一个listen状态,当调用了这个函数时候,服务器就进入了这个状态,这个时候客户端就可以发起连接了。

当经过三次握手之后,连接构建完成,客户端就可以和服务器端进行数据交互了。

内核会贴心地为每个socket维护两个队列,分别用于存储已经构建好的连接和正在构建的连接。

在服务端等待的时候,客户端可以通过connect函数发起连接。先在参数中指明要连接的ip地址和端口号,然后开始发起三次握手。内核会给客户端分配一个临时的端口。一旦握手成功,服务端的accept就会返回另一个socket。即用于监听的socket和真正用于传输的socket是两个,一个叫做监听socket,另外一个叫做已连接socket(思路和单一职责原则类似)。

在这里按照我的理解,之前所说的两个队列应该是仅仅为了监听socket而服务的,毕竟对于已连接socket维护两个队列真的是完全没有必要的!
[image:BDAE0779-031C-4356-9F23-A2BD8628E113-301-00005686E226BB8F/602d09290bd4f9e0183f530e9653348c.jpg]

连接建立之后,就开始通过socket来进行read和write的操作。

当SOCKET基于UDP协议

UDP协议的性格我就很喜欢,所谓的如果我有绝对的实力,那么一切的谋略和把戏都毫无意义。既然我只关心发送,也不用管接收方到底收不收的到,那么,我作为客户端,当我建立起socket并且绑定完毕,直接发送即可,接收不到的话,那就是服务器的问题。所谓的,“错的不是我,而是这个世界”!同样,我作为服务器端,我也只需要建立起一个socket并且绑定完毕,然后我需要做的事情就是摸鱼等客户端传输数据过来,如果没有数据过来,那就是客户端的问题,和我没有关系。
[image:EFD62D14-EC84-455D-B186-D8EE827E8E59-301-0000569B7BD04FB6/778687d1a02ffc0c24078c33be2ac1ef.jpg]

UDP协议就是这个一个互相甩锅的情况,如果双方发现是在没有办法甩锅了,那么就甩锅给网络吧,毕竟,你也不可能把整个网络编程被告。

在TCP协议基础上,服务器如何维护socket?

前面说过了,TCP协议会导致服务器需要维护多个socket,服务器一般是通过一个四元组来标识一个TCP连接。

{本机IP, 本机端口, 对端IP, 对端端口}

我们常常需要通过多个进程,多个线程来维护多个socket,毕竟各个socket之间的通信往往是独立的,所以是可以并行处理的。这里后续涉及到linux进程,线程的维护,以及推拉机制,对于linux半小白的我来说,现在摸透这个来为时尚早,吃力不讨好,等我解决完另一个“趣谈linux系统专栏”之后再来慢慢消化你!
[image:B9E9C501-582F-47C6-BE85-A457069A76A2-301-00005738ADA6F1E2/d353eee3c387332e378c1e517c642f1c.jpg]

[image:5B7E71E8-E63A-4CB0-9253-F65A766606D7-301-00005739D0CB0A11/ab6e0ecfee5e21f7a563999a94bd8bd7.jpg]

[image:96AC6DEA-027D-4C82-B21E-7C2ECD9EBC81-301-0000573B065047DF/cff688ede147809da4d65fe4152ffb19.jpg]


后记

哇,感觉真的过了很长的时间啊,我本来以为晚上还能大概再深入研究研究插件化的相关操作的,但是当前的情况,光是学习和整理一讲的内容,就已经花费了我太多的时间了。时间啊,你真的太让我感到怜惜了!

猜你喜欢

转载自blog.csdn.net/qq_31433709/article/details/107871922