网络编程----心得体会

网络编程：

 

1.首先要对一些名字有些认识，发现他们之间的关系。

文件描述符：

在我看来，就是操作文件的时候，内核给了一个指针而已，但是这个指针在判断的时候对指针进行非空进行判断，进而判断语句是否成功，所以把它搞成数字

 这样在打开文件的时候就变成了数字判断（但实质上是操作那个指针指向的起始地址）。

套接字描述符：

这个更高大上了，在你创建的时候，它是没有初始化的。而且在创建的时候是根据具体协议写出的特殊的套接字（可以携带IP（字符和二进制进行转换的函数）+PORT（由于网络套接字和主机本地套接字的差距演化出转换函数））

在客户端和服务器端进行连接的时候，分为监听套接字 (好比大家都知道的秘书（一个），有事情找某一个老板（老板是一个团队），是要先去找秘书，这个秘书就是监听套接字，只是大家都知道，然后都去找她) +   连接套接字（就是你要和那个老板进行汇报，在你找的时候把这个告诉秘书，秘书给你安排好放在已经连接队列里面（如果到了就把这个老板安排给你见面））

客户或者服务器处理：

在业务处理的时候，我们都是对描述符进行某种处理。套接字描述符号，是用来安排连接见面的。文件描述符是用来通信的，通过操作这个文件描述符实现客户和服务器业务层次的操作。

高并发select模型：

前面也说了，我们是通过操作文件描述符来进行客户端和服务器端业务层次的操作，现在我们通过把文件描述符统一管理起来，然后通过检测这些文件描述符的变化，来进行不同的操作，谁变化代表谁有新请求，咱们就处理谁。是不是提高了效率呢，在某种程度上是可行的。

在这里有没有联想到什么呢？？？想起信号的事情，信号集合，信号阻塞集，都是通过将全部信号管理起来，然后去操作。是不是很相似呢。显然......

重点：建立一个文件描述符集合，将要关心的文件描述符添加到此集合，以上过程是在用户空间发生的。现在运行了进入了内核态，文件描述符发生了变化，现在传递并赋值到用户空间，然后去遍历此集合，看哪些发生了变化，然后进行相应的操作。这样是不是比单个处理提高了效率，但是有个弊端就是频繁的在内核和用户空间来回传递文件描述符的开销很大。单个进程打开的文件描述符有限制，1024，不管集合中的文件描述符变化没有都要进行遍历操作。

poll模型：

这个相比select高大上了，就是将要监视的文件描述符弄成一个结构体数组（内部含有文件描述符(fd)+事件(event)+返回的事件信息(revents)），这个虽然突破了文件描述符大小的限制，但是依然没有解决内核和用户空间来回切换产生的开销。实现机制是这样的：在用户空间进行结构体数组的赋值，然后传递到内核态度，将发生变化的文件描述符对应的事件，赋值给返回的事件信息。等在用户空间我们就去操作结构体数组中的返回事件的信息（revents）（在用户态要分配内存进行状态的存储）,这个好像比select强了很多，但是弊端并没有解决。

之前已经赋值过一次了，在内核态完成了状态变化后，状态进行了变化。在用户态的时候，又将创建临时变量进行存储还有分配内存，因此开销大还是存在。

epoll模型

在我看来是这样子的，解释如下：就是在创建epoll句柄的时候大小设置，无所谓，应该是根据你的设置进行动态分配的。

然后创建两个事件状态，一个临时的不断的改变值，然后添加到wait_event，这个之所以高大上是因为，在内核态的时候，如果状态发生了变化，内核帮助我们把状态信息的变化给赋值到wait_event中，然后用户态是不用额外分配内存进行存储的。而且更重要的是，用户在遍历的时候，只是去查询已经发生变化的那些个状态事件列表，更加高效。

makfile:

其中有部分思想值得我们学习，就是那个我们只关心改变的那些个文件，makefile之所以会这么高效是因为，他不会重复编译，这是它存在那么久的根本袁云，

能够避免重复编译。

轮询：

一个死循环，去查询状态根据状态进行操作。（有没有觉得像是设计模式里面的状态模式）

静态库与动态库：

静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库（这个时候你删除静态库都是可以的）。动态库在程序编译时并不会被连接到目标代码中（推迟了绑定的过程），而是在程序运行是才被载入，因此在程序运行时还需要动态库存在。

他们之间有很多相似的地方，就是都是在头文件中声明函数原型，然后在对应文件中将头文件包含然后编写函数实现。静态库和动态库的来源都

是函数生成的.O文件。然后将生成的.O文件搞成要么是绝对地址，要么是相对地址，这样的话就可以实现共享或者编译时直接编译到源代码中

静态库当你编译进代码的时候，库是可以删除的。但是当你库更新时，是不是使用到库的文件也要相对应的更新，以及编译，这对大工程来说很致命。 而共享库则会解决这个问题，但是它依赖与库，不能离开库。

 

 

 

 

 

 

 

此文会不断更新：