网络编程为什么要双缓冲区

① 我的毕业设计是一片关于网络渗透技术的论文，求能人给点相关的资料和文献，本人是毫无头绪啊。

[计算机科学与技术 ]Web服务缓冲区溢出渗透测试的设计与实现
http://ww2.tabobo.cn/soft/20/233/2007/14452478777.html

摘 要
缓冲区溢出漏洞是安全漏洞中最为常见的一种形式。更为严重的是缓冲区溢出漏洞占了远程网络攻击的绝大多数，这种攻击可以使的一个匿名的Internet用户有机会获得一台主机的部分或全部的控制权。由于这类攻击使任何人都有可能取得主机的控制权，所以它代表了一类极其严重的安全威胁。因此，以缓冲区溢出作为一种渗透测试的手段是非常有意义的。
缓冲区溢出是渗透测试中的重要手段。现在大多数缓冲区溢出程序都是基于C/S架构的，所以其使用的便捷性受到一定限制。本课题采用现在最流行的B/S架构，并且最终实现了将缓冲区溢出作为Web服务来检测远程主机有无溢出漏洞并提醒用户尽快修补此漏洞的目的。本文深入介绍了缓冲区溢出的原理，以及三种常见的缓冲区溢出漏洞；实例化地介绍了缓冲区溢出程序的执行流程；shellcode的编写技术；java网络编程技术。
在对原理研究的基础之上，本文主要给出了缓冲区溢出作为Web服务的设计和实现过程以及Web服务的其他辅助功能块（网络安全新闻管理、网络安全论坛）的设计和实现。其中缓冲区溢出模块和监听模块采用JavaBean技术实现，其他部分均采用JSP技术加以实现。
总的来说，本渗透测试平台实现了缓冲区溢出的方便性和广范性以及安全性，并且可以加载任意的已经编译成可执行文件的溢出程序。比起传统的C/S架构下的测试平台前进了一大步。

关键字：渗透测试、缓冲区溢出、JSP

目 录
摘要 1
Abstract 2
第一章 绪论 5
1.1 课题背景 5
1.2渗透测试概述 5
1.2.1渗透测试的的专业性 6
1.2.2 渗透测试的三个阶段 6
1.3 论文安排 8
第二章 缓冲区溢出攻击技术 9
2.1 缓冲区溢出基本原理 9
2.2 常见的缓冲区溢出形式 11
2.2.1 栈溢出 11
2.2.2 堆溢出 12
2.2.3 格式化字符串溢出 13
2.3 缓冲区溢出执行流程 16
2.4 shellcode技术 19
2.4.1 shellcode的编写语言 19
2.4.2 shellcode本身代码的重定位 20
2.4.3 shellcode编码 21
第三章 Java网络编程技术介绍.23
3.1 JavaBean技术 23
3.1.1 JavaBean的概念 23
3.1.2 JavaBean的特性 23
3.1.3 JavaBean的属性23
3.1.4 JavaBean在JSP页面里的部署24
3.2 socket网络编程技术 .24
3.3 Java数据流 25
3.3.1 数据流的基本概念 25
3.3.2 数据流的分类介绍 25
第四章 缓冲区溢出渗透测试平台的设计与实现 27
4.1 测试平台框架设计27
4.1.1整体框架设计 27
4.1.2网络安全新闻发布模块设计 28
4.1.3网络安全论坛模块设计 29
4.1.4缓冲区溢出渗透测试模块设计 31
4.2 缓冲区溢出渗透测试编码实现 34
4.2.1缓冲区溢出漏洞选择 34
4.2.2溢出模块实现 34
4.2.3监听模块实现 34
4.2.4本地执行命令实现 36
4.2.5缓冲区溢出状态实现 39
第五章 实验设计和实验数据 42
5.1实验准备 42
5.2 SqlServer2000打sp3补丁前 43
5.2.1实验数据 43
5.3 SqlServer2000打sp3补丁后 45
5.3.1实验数据 45
结束语 47
参考文献 48
致 谢 49

② 网络编程里的同步和异步有啥区别的

网络编程中，同步的意思是说，进行收发数据，等到数据真正发送出去或者接受到，才返回；而异步的意思是，可以把数据发送到缓冲区立即返回，而发送成功的消息是通过事件通知的。异步可以腾出更多的CPU来处理其他事情，所以异步的方式比较灵活。 线程同步是指，多个线程协同完成一件工作，一个线程需要等待其他线程完成相关的工作，才能接着往下运行。线程同步一般采用互斥体，信号量，消息等方式。

③ java Nio读写为什么是双向

作者：美团技术团队
链接：https://zhuanlan.hu.com/p/23488863
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

NIO（Non-blocking I/O，在Java领域，也称为New I/O），是一种同步非阻塞的I/O模型，也是I/O多路复用的基础，已经被越来越多地应用到大型应用服务器，成为解决高并发与大量连接、I/O处理问题的有效方式。

那么NIO的本质是什么样的呢？它是怎样与事件模型结合来解放线程、提高系统吞吐的呢？

本文会从传统的阻塞I/O和线程池模型面临的问题讲起，然后对比几种常见I/O模型，一步步分析NIO怎么利用事件模型处理I/O，解决线程池瓶颈处理海量连接，包括利用面向事件的方式编写服务端/客户端程序。最后延展到一些高级主题，如Reactor与Proactor模型的对比、Selector的唤醒、Buffer的选择等。

注：本文的代码都是伪代码，主要是为了示意，不可用于生产环境。

传统BIO模型分析

让我们先回忆一下传统的服务器端同步阻塞I/O处理（也就是BIO，Blocking I/O）的经典编程模型：

{
ExecutorService executor = Excutors.newFixedThreadPollExecutor(100);//线程池

ServerSocket serverSocket = new ServerSocket();
serverSocket.bind(8088);
while(!Thread.currentThread.isInturrupted()){//主线程死循环等待新连接到来
Socket socket = serverSocket.accept();
executor.submit(new ConnectIOnHandler(socket));//为新的连接创建新的线程
}

class ConnectIOnHandler extends Thread{
private Socket socket;
public ConnectIOnHandler(Socket socket){
this.socket = socket;
}
public void run(){
while(!Thread.currentThread.isInturrupted()&&!socket.isClosed()){死循环处理读写事件
String someThing = socket.read()....//读取数据
if(someThing!=null){
......//处理数据
socket.write()....//写数据
}

}
}
}

这是一个经典的每连接每线程的模型，之所以使用多线程，主要原因在于socket.accept()、socket.read()、socket.write()三个主要函数都是同步阻塞的，当一个连接在处理I/O的时候，系统是阻塞的，如果是单线程的话必然就挂死在那里；但CPU是被释放出来的，开启多线程，就可以让CPU去处理更多的事情。其实这也是所有使用多线程的本质：

• 利用多核。

• 当I/O阻塞系统，但CPU空闲的时候，可以利用多线程使用CPU资源。

现在的多线程一般都使用线程池，可以让线程的创建和回收成本相对较低。在活动连接数不是特别高（小于单机1000）的情况下，这种模型是比较不错的，可以让每一个连接专注于自己的I/O并且编程模型简单，也不用过多考虑系统的过载、限流等问题。线程池本身就是一个天然的漏斗，可以缓冲一些系统处理不了的连接或请求。

不过，这个模型最本质的问题在于，严重依赖于线程。但线程是很"贵"的资源，主要表现在：

• 线程的创建和销毁成本很高，在linux这样的操作系统中，线程本质上就是一个进程。创建和销毁都是重量级的系统函数。

• 线程本身占用较大内存，像Java的线程栈，一般至少分配512K～1M的空间，如果系统中的线程数过千，恐怕整个JVM的内存都会被吃掉一半。

• 线程的切换成本是很高的。操作系统发生线程切换的时候，需要保留线程的上下文，然后执行系统调用。如果线程数过高，可能执行线程切换的时间甚至会大于线程执行的时间，这时候带来的表现往往是系统load偏高、CPU sy使用率特别高（超过20%以上)，导致系统几乎陷入不可用的状态。

• 容易造成锯齿状的系统负载。因为系统负载是用活动线程数或CPU核心数，一旦线程数量高但外部网络环境不是很稳定，就很容易造成大量请求的结果同时返回，激活大量阻塞线程从而使系统负载压力过大。

所以，当面对十万甚至百万级连接的时候，传统的BIO模型是无能为力的。随着移动端应用的兴起和各种网络游戏的盛行，百万级长连接日趋普遍，此时，必然需要一种更高效的I/O处理模型。

NIO是怎么工作的

很多刚接触NIO的人，第一眼看到的就是Java相对晦涩的API，比如：Channel，Selector，Socket什么的；然后就是一坨上百行的代码来演示NIO的服务端Demo……瞬间头大有没有？

我们不管这些，抛开现象看本质，先分析下NIO是怎么工作的。

常见I/O模型对比

所有的系统I/O都分为两个阶段：等待就绪和操作。举例来说，读函数，分为等待系统可读和真正的读；同理，写函数分为等待网卡可以写和真正的写。

需要说明的是等待就绪的阻塞是不使用CPU的，是在“空等”；而真正的读写操作的阻塞是使用CPU的，真正在"干活"，而且这个过程非常快，属于memory ，带宽通常在1GB/s级别以上，可以理解为基本不耗时。

下图是几种常见I/O模型的对比：



密码：380p

以上都是小编收集了大神的灵药，喜欢的拿走吧！喜欢小编就轻轻关注一下吧！

④ linux网络编程，为什么要将文件描述符设置成非阻塞模式

非阻塞IO 和阻塞IO：

在网络编程中对于一个网络句柄会遇到阻塞IO 和非阻塞IO 的概念, 这里对于这两种socket 先做一下说明：
基本概念：
阻塞IO::
socket 的阻塞模式意味着必须要做完IO 操作（包括错误）才会
返回。
非阻塞IO::
非阻塞模式下无论操作是否完成都会立刻返回，需要通过其他方
式来判断具体操作是否成功。(对于connect，accpet操作，通过select判断，
对于recv，recvfrom，send，sendto通过返回值+错误码来判断)

IO模式设置：
SOCKET
对于一个socket 是阻塞模式还是非阻塞模式的处理方法::
方法：：
用fcntl 设置;用F_GETFL获取flags,用F_SETFL设置flags|O_NONBLOCK;
同时，recv,send 时使用非阻塞的方式读取和发送消息，即flags设置为MSG_DONTWAIT
实现
fcntl 函数可以将一个socket 句柄设置成非阻塞模式:
flags = fcntl(sockfd, F_GETFL, 0); //获取文件的flags值。
fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); //设置成非阻塞模式；
flags = fcntl(sockfd,F_GETFL,0);
fcntl(sockfd,F_SETFL,flags&~O_NONBLOCK); //设置成阻塞模式；
并在接收和发送数据时:
将recv, send 函数的最后有一个flag 参数设置成MSG_DONTWAIT
recv(sockfd, buff, buff_size,MSG_DONTWAIT); //非阻塞模式的消息发送
send(scokfd, buff, buff_size, MSG_DONTWAIT); //非阻塞模式的消息接受

普通文件
对于文件的阻塞模式还是非阻塞模式::
方法1、open时，使用O_NONBLOCK；
方法2、fcntl设置，使用F_SETFL，flags|O_NONBLOCK；

消息队列
对于消息队列消息的发送与接受::
//非阻塞 msgsnd(sockfd,msgbuf,msgsize(不包含类型大小),IPC_NOWAIT)
//阻塞 msgrcv(scokfd,msgbuf,msgsize(**),msgtype,IPC_NOWAIT);

读
阻塞与非阻塞读的区别: //阻塞和非阻塞的区别在于没有数据到达的时候是否立刻返回．
读(read/recv/msgrcv):
读的本质来说其实不能是读,在实际中, 具体的接收数据不是由这些调用来进行,是由于系统底层自动完成的。read 也好,recv 也好只负责把数据从底层缓冲 到我们指定的位置.
对于读来说(read, 或者recv) ::
阻塞情况下::
在阻塞条件下，read/recv/msgrcv的行为::
1、如果没有发现数据在网络缓冲中会一直等待，
2、当发现有数据的时候会把数据读到用户指定的缓冲区，但是如果这个时候读到的数据量比较少，比参数中指定的长度要小，read 并不会一直等待下去，而是立刻返回。
read 的原则::是数据在不超过指定的长度的时候有多少读多少，没有数据就会一直等待。
所以一般情况下::我们读取数据都需要采用循环读的方式读取数据，因为一次read 完毕不能保证读到我们需要长度的数据，
read 完一次需要判断读到的数据长度再决定是否还需要再次读取。
非阻塞情况下::
在非阻塞的情况下，read 的行为::
1、如果发现没有数据就直接返回，
2、如果发现有数据那么也是采用有多少读多少的进行处理．
所以::read 完一次需要判断读到的数据长度再决定是否还需要再次读取。

对于读而言:: 阻塞和非阻塞的区别在于没有数据到达的时候是否立刻返回．
recv 中有一个MSG_WAITALL 的参数::
recv(sockfd, buff, buff_size, MSG_WAITALL),
在正常情况下recv 是会等待直到读取到buff_size 长度的数据，但是这里的WAITALL 也只是尽量读全，在有中断的情况下recv 还是可能会被打断，造成没有读完指定的buff_size的长度。
所以即使是采用recv + WAITALL 参数还是要考虑是否需要循环读取的问题，在实验中对于多数情况下recv (使用了MSG_WAITALL)还是可以读完buff_size，
所以相应的性能会比直接read 进行循环读要好一些。

注意:: //使用MSG_WAITALL时，sockfd必须处于阻塞模式下，否则不起作用。
//所以MSG_WAITALL不能和MSG_NONBLOCK同时使用。
要注意的是使用MSG_WAITALL的时候，sockfd 必须是处于阻塞模式下，否则WAITALL不能起作用。

写

阻塞与非阻塞写的区别: //
写(send/write/msgsnd)::
写的本质也不是进行发送操作,而是把用户态的数据 到系统底层去,然后再由系统进行发送操作,send，write返回成功，只表示数据已经 到底层缓冲,而不表示数据已经发出,更不能表示对方端口已经接收到数据.
对于write(或者send)而言，
阻塞情况下:: //阻塞情况下，write会将数据发送完。(不过可能被中断)
在阻塞的情况下，是会一直等待，直到write 完，全部的数据再返回．这点行为上与读操作有所不同。
原因::
读，究其原因主要是读数据的时候我们并不知道对端到底有没有数据，数据是在什么时候结束发送的，如果一直等待就可能会造成死循环，所以并没有去进行这方面的处理；
写，而对于write, 由于需要写的长度是已知的，所以可以一直再写，直到写完．不过问题是write 是可能被打断吗，造成write 一次只write 一部分数据, 所以write 的过程还是需要考虑循环write, 只不过多数情况下一次write 调用就可能成功.

非阻塞写的情况下:: //
非阻塞写的情况下，是采用可以写多少就写多少的策略．与读不一样的地方在于，有多少读多少是由网络发送的那一端是否有数据传输到为标准，但是对于可以写多少是由本地的网络堵塞情况为标准的，在网络阻塞严重的时候，网络层没有足够的内存来进行写操作，这时候就会出现写不成功的情况，阻塞情况下会尽可能(有可能被中断)等待到数据全部发送完毕， 对于非阻塞的情况就是一次写多少算多少,没有中断的情况下也还是会出现write 到一部分的情况.