关于tcp端口扫描方式包括的信息

C++ TCP端口扫描

差不多就是这样的吧

#include stdio.h

#include winsock.h

#pragma comment(lib,"wsock32.lib")

int main(int argc, char **argv)

{

SOCKET sd_client;

u_short iPortStart, iPortEnd, port;

struct sockaddr_in addr_srv;

char *pszHost;

WSADATA wsaData;

WORD wVersionRequested;

int err;

switch(argc)

{

case 2:

iPortStart = 0;

iPortEnd = 65535;

pszHost =argv[1];

break;

case 3:

iPortStart = iPortEnd = atoi(argv[2]);

pszHost =argv[1];

break;

case 4:

iPortStart = atoi(argv[2]);

iPortEnd = atoi(argv[3]);

pszHost =argv[1];

break;

default:

printf("正确的命令行参数：\n");

printf("[IP] 扫描所有端口\n");

printf("[IP] [端口]：扫描单个端口\n");

printf("[IP] [端口1] [端口2]：扫描端口1到端口2\n");

return 1;

}

wVersionRequested = MAKEWORD( 1, 1 );

err = WSAStartup( wVersionRequested, wsaData );

if ( err != 0 )

{

printf("Error %d: Winsock not available\n", err);

return 1;

}

for(port=iPortStart; port=iPortEnd; port++)

{

sd_client = socket(PF_INET, SOCK_STREAM, 0);

if (sd_client == INVALID_SOCKET)

{

printf("no more socket resources\n");

return 1;

}

addr_srv.sin_family = PF_INET;

addr_srv.sin_addr.s_addr=inet_addr(pszHost);

addr_srv.sin_port = htons(port);

err = connect(sd_client, (struct sockaddr *) addr_srv, sizeof(addr_srv));

if (err == INVALID_SOCKET)

{

printf("不能连接此端口:%d\n", port);

closesocket(sd_client);

continue;

}

printf("扫描此端口成功:%d\n", port);

closesocket(sd_client);

}

WSACleanup();

return 0;

}

TCP协议详解及实战解析【精心整理收藏】

TCP协议是在TCP/IP协议模型中的运输层中很重要的一个协议、负责处理主机端口层面之间的数据传输。主要有以下特点：

1.TCP是面向链接的协议，在数据传输之前需要通过三次握手建立TCP链接，当数据传递完成之后，需要通过四次挥手进行连接释放。

2.每一条TCP通信都是两台主机和主机之间的，是点对点传输的协议。

3.TCP提供可靠的、无差错、不丢失、不重复，按序到达的服务。

4.TCP的通信双方在连接建立的任何时候都可以发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。

5.面向字节流。在数据传输的过程中如果报文比较长的话TCP会进行数据分段传输，每一条分段的TCP传输信息都带有分段的序号，每一段都包含一部分字节流。接收方根据每段携带的的序号信息进行数据拼接，最终拼接出来初始的传输数据。但是在整个传输的过程中每一段TCP携带的都是被切割的字节流数据。所以说TCP是面向字节流的。

a.TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用程序一次把多长的报文发送到TCP缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用程序给出的）。

b.如果应用程序传送到TCP缓存的数据块太大，TCP就可以把它划分短一些再传。TCP也可以等待积累有足够多的字节后再构建成报文段发送出去。

各字段含义：

源端口：发送端的端口号

目的端口：接收端的端口号

序号：TCP将发送报文分段传输的时候会给每一段加上序号，接收端也可以根据这个序号来判断数据拼接的顺序，主要用来解决网络报乱序的问题

确认号：确认号为接收端收到数据之后进行排序确认以及发送下一次期待接收到的序号，数值 = 接收到的发送号 + 1

数据偏移：占4比特，表示数据开始的地方离TCP段的起始处有多远。实际上就是TCP段首部的长度。由于首部长度不固定，因此数据偏移字段是必要的。数据偏移以32位为长度单位，因此TCP首部的最大长度是60（15*4）个字节。

控制位：

URG：此标志表示TCP包的紧急指针域有效，用来保证TCP连接不被中断，并且督促 中间层设备要尽快处理这些数据;

ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中;有两个取值：0和1， 为1的时候表示应答域有效，反之为0;

PSH：这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序， 而不是在缓冲区中排队;

RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包;

SYN：表示同步序号，用来建立连接。SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1， ACK=0;连接被响应的时候，SYN=1，ACK=1;这个标志的数据包经常被用来进行端口扫描。扫描者发送 一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口;但是由于这 种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全 的主机将会强制要求一个连接严格的进行TCP的三次握手;

FIN： 表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志 位的TCP数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。

窗口：TCP里很重要的一个机制，占2字节，表示报文段发送方期望接收的字节数，可接收的序号范围是从接收方的确认号开始到确认号加上窗口大小之间的数据。后面会有实例讲解。

校验和：校验和包含了伪首部、TCP首部和数据，校验和是TCP强制要求的，由发送方计算，接收方验证

紧急指针：URG标志为1时，紧急指针有效，表示数据需要优先处理。紧急指针指出在TCP段中的紧急数据的最后一个字节的序号，使接收方可以知道紧急数据共有多长。

选项：最常用的选项是最大段大小（Maximum Segment Size，MSS），向对方通知本机可以接收的最大TCP段长度。MSS选项只在建立连接的请求中发送。

放在以太网帧里看TCP的位置

TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。

因此，一条1500字节的信息需要两个 TCP 数据包。HTTP/2 协议的一大改进， 就是压缩 HTTP 协议的头信息，使得一个 HTTP 请求可以放在一个 TCP 数据包里面，而不是分成多个，这样就提高了速度。

以太网数据包的负载是1500字节，TCP 数据包的负载在1400字节左右

一个包1400字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送7100多个包。

发送的时候，TCP 协议为每个包编号（sequence number，简称 SEQ），以便接收的一方按照顺序还原。万一发生丢包，也可以知道丢失的是哪一个包。

第一个包的编号是一个随机数。为了便于理解，这里就把它称为1号包。假定这个包的负载长度是100字节，那么可以推算出下一个包的编号应该是101。这就是说，每个数据包都可以得到两个编号：自身的编号，以及下一个包的编号。接收方由此知道，应该按照什么顺序将它们还原成原始文件。

收到 TCP 数据包以后，组装还原是操作系统完成的。应用程序不会直接处理 TCP 数据包。

对于应用程序来说，不用关心数据通信的细节。除非线路异常，否则收到的总是完整的数据。应用程序需要的数据放在 TCP 数据包里面，有自己的格式（比如 HTTP 协议）。

TCP 并没有提供任何机制，表示原始文件的大小，这由应用层的协议来规定。比如，HTTP 协议就有一个头信息Content-Length，表示信息体的大小。对于操作系统来说，就是持续地接收 TCP 数据包，将它们按照顺序组装好，一个包都不少。

操作系统不会去处理 TCP 数据包里面的数据。一旦组装好 TCP 数据包，就把它们转交给应用程序。TCP 数据包里面有一个端口（port）参数，就是用来指定转交给监听该端口的应用程序。

应用程序收到组装好的原始数据，以浏览器为例，就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着，一次 TCP 通信可以包括多个 HTTP 通信。

服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。

最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？答案就是慢慢试。

TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率：如果不丢包，就加快发送速度；如果丢包，就降低发送速度。

Linux 内核里面 设定 了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个数据包，即"发送窗口"的大小为10。然后停下来，等待接收方的确认，再继续发送。

默认情况下，接收方每收到 两个 TCP 数据包，就要 发送 一个确认消息。"确认"的英语是 acknowledgement，所以这个确认消息就简称 ACK。

ACK 携带两个信息。

发送方有了这两个信息，再加上自己已经发出的数据包的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为"发送窗口"，这个窗口的大小是可变的。

注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个数据包里面发送。

即使对于带宽很大、线路很好的连接，TCP 也总是从10个数据包开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。

TCP 协议可以保证数据通信的完整性，这是怎么做到的？

前面说过，每一个数据包都带有下一个数据包的编号。如果下一个数据包没有收到，那么 ACK 的编号就不会发生变化。

举例来说，现在收到了4号包，但是没有收到5号包。ACK 就会记录，期待收到5号包。过了一段时间，5号包收到了，那么下一轮 ACK 会更新编号。如果5号包还是没收到，但是收到了6号包或7号包，那么 ACK 里面的编号不会变化，总是显示5号包。这会导致大量重复内容的 ACK。

如果发送方发现收到 三个 连续的重复 ACK，或者超时了还没有收到任何 ACK，就会确认丢包，即5号包遗失了，从而再次发送这个包。通过这种机制，TCP 保证了不会有数据包丢失。

TCP是一个滑动窗口协议，即一个TCP连接的发送端在某个时刻能发多少数据是由滑动窗口控制的，而滑动窗口的大小实际上是由两个窗口共同决定的，一个是接收端的通告窗口，这个窗口值在TCP协议头部信息中有，会随着数据的ACK包发送给发送端，这个值表示的是在接收端的TCP协议缓存中还有多少剩余空间，发送端必须保证发送的数据不超过这个剩余空间以免造成缓冲区溢出，这个窗口是接收端用来进行流量限制的，在传输过程中，通告窗口大小与接收端的进程取出数据的快慢有关。另一个窗口是发送端的拥塞窗口(Congestion window)，由发送端维护这个值，在协议头部信息中没有，滑动窗口的大小就是通告窗口和拥塞窗口的较小值，所以拥塞窗口也看做是发送端用来进行流量控制的窗口。滑动窗口的左边沿向右移动称为窗口合拢，发生在发送的数据被确认时（此时，表明数据已被接收端收到，不会再被需要重传，可以从发送端的发送缓存中清除了），滑动窗口的右边沿向右移动称为窗口张开，发生在接收进程从接收端协议缓存中取出数据时。随着发送端不断收到的被发送数据的ACK包，根据ACK包中的确认序号和通告窗口大小使滑动窗口得以不断的合拢和张开，形成滑动窗口的向前滑动。如果接收进程一直不取数据，则会出现0窗口现象，即滑动窗口左边沿与右边沿重合，此时窗口大小为0，就无法再发送数据。

在TCP里，接收端(B)会给发送端(A)报一个窗口的大小，叫Advertised window。

1.在没有收到B的确认情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在

未收到确认之前都必须暂时保留，以便在超时重传时使用。

2.发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续

发送更多数据，因而可能获得更高的传输效率。但接收方必须来得及处理这些收到的数据。

3.发送窗口后沿的后面部分表示已发送且已收到确认。这些数据显然不需要再保留了。

4.发送窗口前沿的前面部分表示不允许发送的，应为接收方都没有为这部分数据保留临时存放的缓存空间。

5.发送窗口后沿的变化情况有两种：不动（没有收到新的确认）和前移（收到了新的确认）

6.发送窗口前沿的变化情况有两种：不断向前移或可能不动（没收到新的确认）

TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段。这种重传的概念很简单，但重传时间的选择确是TCP最复杂的问题之一。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到响应的确认的时间

这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间。超时重传时间RTO略大于加权平均往返时间

RTT：

即Round Trip Time，表示从发送端到接收端的一去一回需要的时间，tcp在数据传输过程中会对RTT进行采样（即对发送的数据包及其ACK的时间差进行测量，并根据测量值更新RTT值，具体的算法TCPIP详解里面有），TCP根据得到的RTT值更新RTO值，即Retransmission TimeOut，就是重传间隔，发送端对每个发出的数据包进行计时，如果在RTO时间内没有收到所发出的数据包的对应ACK，则任务数据包丢失，将重传数据。一般RTO值都比采样得到的RTT值要大。

如果收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？

答案是可以的，选择确认就是一种可行的处理方法。

如果要使用选项确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。如果使用选择确认，

那么原来首部中的“确认号字段”的用法仍然不变。SACK文档并没有明确发送方应当怎么响应SACK.因此大多数的实现还是重传所有未被确认的数据块。

一般说来，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

在计算机网络中的链路容量，交换节点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。

拥塞控制方法：

1.慢开始和拥塞避免

2.快重传和快恢复

3.随机早期检测

1.一开始，客户端和服务端都处于CLOSED状态

2.先是服务端主动监听某个端口，处于LISTEN状态（比如服务端启动，开始监听）。

3.客户端主动发起连接SYN，之后处于SYN-SENT状态（第一次握手，发送 SYN = 1 ACK = 0 seq = x ack = 0）。

4.服务端收到发起的连接，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态（第二次握手，发送 SYN = 1 ACK = 1 seq = y ack = x + 1）。

5.客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态（第三次握手，发送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1）。

6.服务端收到客户端的ACK之后，处于ESTABLISHED状态。

（需要注意的是，有可能X和Y是相等的，可能都是0，因为他们代表了各自发送报文段的序号。）

TCP连接释放四次挥手

1.当前A和B都处于ESTAB-LISHED状态。

2.A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。

3.B收到连接释放报文段后即发出确认，然后B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时TCP连接处于半关闭状态，即A已经没有数据发送了。

从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。

4.A收到来自B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文端。

5.若B已经没有向A发送的数据，B发出连接释放信号，这时B进入LAST-ACK(最后确认)状态等待A的确认。

6.A再收到B的连接释放消息后，必须对此发出确认，然后进入TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉，必须经过时间等待计时器（TIME－WAIT timer）设置的时间2MSL后，A才进入CLOSED状态。

7。B收到A发出的确认消息后，进入CLOSED状态。

以请求百度为例，看一下三次握手真实数据的TCP连接建立过程

我们再来看四次挥手。TCP断开连接时，会有四次挥手过程，标志位是FIN，我们在封包列表中找到对应位置，理论上应该找到4个数据包，但我试了好几次，实际只抓到3个数据包。查了相关资料，说是因为服务器端在给客户端传回的过程中，将两个连续发送的包进行了合并。因此下面会按照合并后的三次挥手解释，若有错误之处请指出。

第一步，当主机A的应用程序通知TCP数据已经发送完毕时，TCP向主机B发送一个带有FIN附加标记的报文段（FIN表示英文finish）。

第二步，主机B收到这个FIN报文段之后，并不立即用FIN报文段回复主机A，而是先向主机A发送一个确认序号ACK，同时通知自己相应的应用程序：对方要求关闭连接（先发送ACK的目的是为了防止在这段时间内，对方重传FIN报文段）。

第三步，主机B的应用程序告诉TCP：我要彻底的关闭连接，TCP向主机A送一个FIN报文段。

第四步，主机A收到这个FIN报文段后，向主机B发送一个ACK表示连接彻底释放。

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

原因有二：

一、保证TCP协议的全双工连接能够可靠关闭

二、保证这次连接的重复数据段从网络中消失

先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

硬件速度

网络和服务器的负载

请求和响应报文的尺寸

客户端和服务器之间的距离

TCP 协议的技术复杂性

TCP 连接建立握手；

TCP 慢启动拥塞控制；

数据聚集的 Nagle 算法；

用于捎带确认的 TCP 延迟确认算法；

TIME_WAIT 时延和端口耗尽。

介绍完毕，就这？

是的，就这。

补充：

大部分内容为网络整理，方便自己学习回顾，参考文章：

TCP 协议简介

TCP协议图文详解

什么是TCP协议？

wireshark抓包分析——TCP/IP协议

TCP协议的三次握手和四次挥手

TCP协议详解

TCP带宽和时延的研究(1)

请给出TCP connect()这个函数的所有参数及其解释？

所有参数及其解释如下：

-sT

TCP connect()扫描：这是最基本的TCP扫描方式。connect()是一种系统调用，由操作系统提供，用来打开一个连接。如果目标端口有程序监听，connect()就会成功返回，否则这个端口是不可达的。这项技术最大的优点是，你勿需root权限。任何UNIX用户都可以自由使用这个系统调用。这种扫描很容易被检测到，在目标主机的日志中会记录大批的连接请求以及错误信息。

-sS

TCP同步扫描(TCP SYN)：因为不必全部打开一个TCP连接，所以这项技术通常称为半开扫描(half-open)。你可以发出一个TCP同步包(SYN)，然后等待回应。如果对方返回SYN|ACK(响应)包就表示目标端口正在监听；如果返回RST数据包，就表示目标端口没有监听程序；如果收到一个SYN|ACK包，源主机就会马上发出一个RST(复位)数据包断开和目标主机的连接，这实际上有我们的操作系统内核自动完成的。这项技术最大的好处是，很少有系统能够把这记入系统日志。不过，你需要root权限来定制SYN数据包。

-sF -sF -sN

秘密FIN数据包扫描、圣诞树(Xmas Tree)、空(Null)扫描模式：即使SYN扫描都无法确定的情况下使用。一些防火墙和包过滤软件能够对发送到被限制端口的SYN数据包进行监视，而且有些程序比如synlogger和courtney能够检测那些扫描。这些高级的扫描方式可以逃过这些干扰。这些扫描方式的理论依据是：关闭的端口需要对你的探测包回应RST包，而打开的端口必需忽略有问题的包(参考RFC 793第64页)。FIN扫描使用暴露的FIN数据包来探测，而圣诞树扫描打开数据包的FIN、URG和PUSH标志。不幸的是，微软决定完全忽略这个标准，另起炉灶。所以这种扫描方式对Windows95/NT无效。不过，从另外的角度讲，可以使用这种方式来分别两种不同的平台。如果使用这种扫描方式可以发现打开的端口，你就可以确定目标注意运行的不是Windows系统。如果使用-sF、-sX或者-sN扫描显示所有的端口都是关闭的，而使用SYN扫描显示有打开的端口，你可以确定目标主机可能运行的是Windwos系统。现在这种方式没有什么太大的用处，因为nmap有内嵌的操作系统检测功能。还有其它几个系统使用和windows同样的处理方式，包括Cisco、BSDI、HP/UX、MYS、IRIX。在应该抛弃数据包时，以上这些系统都会从打开的端口发出复位数据包。

-sP

ping扫描：有时你只是想知道此时网络上哪些主机正在运行。通过向你指定的网络内的每个IP地址发送ICMP echo请求数据包，nmap就可以完成这项任务。如果主机正在运行就会作出响应。不幸的是，一些站点例如：microsoft.com阻塞ICMP echo请求数据包。然而，在默认的情况下nmap也能够向80端口发送TCP ack包，如果你收到一个RST包，就表示主机正在运行。nmap使用的第三种技术是：发送一个SYN包，然后等待一个RST或者SYN/ACK包。对于非root用户，nmap使用connect()方法。

在默认的情况下(root用户)，nmap并行使用ICMP和ACK技术。

注意，nmap在任何情况下都会进行ping扫描，只有目标主机处于运行状态，才会进行后续的扫描。如果你只是想知道目标主机是否运行，而不想进行其它扫描，才会用到这个选项。

-sU

UDP扫描：如果你想知道在某台主机上提供哪些UDP(用户数据报协议,RFC768)服务，可以使用这种扫描方法。nmap首先向目标主机的每个端口发出一个0字节的UDP包，如果我们收到端口不可达的ICMP消息，端口就是关闭的，否则我们就假设它是打开的。

有些人可能会想UDP扫描是没有什么意思的。但是，我经常会想到最近出现的solaris rpcbind缺陷。rpcbind隐藏在一个未公开的UDP端口上，这个端口号大于32770。所以即使端口111(portmap的众所周知端口号)被防火墙阻塞有关系。但是你能发现大于30000的哪个端口上有程序正在监听吗?使用UDP扫描就能！cDc Back Orifice的后门程序就隐藏在Windows主机的一个可配置的UDP端口中。不考虑一些通常的安全缺陷，一些服务例如:snmp、tftp、NFS使用UDP协议。不幸的是，UDP扫描有时非常缓慢，因为大多数主机限制ICMP错误信息的比例(在RFC1812中的建议)。例如，在Linux内核中(在net/ipv4/icmp.h文件中)限制每4秒钟只能出现80条目标不可达的ICMP消息，如果超过这个比例，就会给1/4秒钟的处罚。solaris的限制更加严格，每秒钟只允许出现大约2条ICMP不可达消息，这样，使扫描更加缓慢。nmap会检测这个限制的比例，减缓发送速度，而不是发送大量的将被目标主机丢弃的无用数据包。

不过Micro$oft忽略了RFC1812的这个建议，不对这个比例做任何的限制。所以我们可以能够快速扫描运行Win95/NT的主机上的所有65K个端口。

-sA

ACK扫描：这项高级的扫描方法通常用来穿过防火墙的规则集。通常情况下，这有助于确定一个防火墙是功能比较完善的或者是一个简单的包过滤程序，只是阻塞进入的SYN包。

这种扫描是向特定的端口发送ACK包(使用随机的应答/序列号)。如果返回一个RST包，这个端口就标记为unfiltered状态。如果什么都没有返回，或者返回一个不可达ICMP消息，这个端口就归入filtered类。注意，nmap通常不输出unfiltered的端口，所以在输出中通常不显示所有被探测的端口。显然，这种扫描方式不能找出处于打开状态的端口。

-sW

对滑动窗口的扫描：这项高级扫描技术非常类似于ACK扫描，除了它有时可以检测到处于打开状态的端口，因为滑动窗口的大小是不规则的，有些操作系统可以报告其大小。这些系统至少包括：某些版本的AIX、Amiga、BeOS、BSDI、Cray、Tru64 UNIX、DG/UX、OpenVMS、Digital UNIX、OpenBSD、OpenStep、QNX、Rhapsody、SunOS 4.x、Ultrix、VAX、VXWORKS。从nmap-hackers邮件3列表的文档中可以得到完整的列表。

-sR

RPC扫描。这种方法和nmap的其它不同的端口扫描方法结合使用。选择所有处于打开状态的端口向它们发出SunRPC程序的NULL命令，以确定它们是否是RPC端口，如果是，就确定是哪种软件及其版本号。因此你能够获得防火墙的一些信息。诱饵扫描现在还不能和RPC扫描结合使用。

-b

FTP反弹攻击(bounce attack):FTP协议(RFC 959)有一个很有意思的特征，它支持代理FTP连接。也就是说，我能够从evil.com连接到FTP服务器target.com，并且可以要求这台FTP服务器为自己发送Internet上任何地方的文件！1985年，RFC959完成时，这个特征就能很好地工作了。然而，在今天的Internet中，我们不能让人们劫持FTP服务器，让它向Internet上的任意节点发送数据。如同Hobbit在1995年写的文章中所说的，这个协议"能够用来做投递虚拟的不可达邮件和新闻，进入各种站点的服务器,填满硬盘，跳过防火墙，以及其它的骚扰活动，而且很难进行追踪"。我们可以使用这个特征，在一台代理FTP服务器扫描TCP端口。因此，你需要连接到防火墙后面的一台FTP服务器，接着进行端口扫描。如果在这台FTP服务器中有可读写的目录，你还可以向目标端口任意发送数据(不过nmap不能为你做这些)。

传递给-b功能选项的参数是你要作为代理的FTP服务器。语法格式为：

-b username:password@server:port。

除了server以外，其余都是可选的。如果你想知道什么服务器有这种缺陷，可以参考我在Phrack 51发表的文章。还可以在nmap的站点得到这篇文章的最新版本。

4.2 通用选项

这些内容不是必需的，但是很有用。

-P0

在扫描之前，不必ping主机。有些网络的防火墙不允许ICMP echo请求穿过，使用这个选项可以对这些网络进行扫描。microsoft.com就是一个例子，因此在扫描这个站点时，你应该一直使用-P0或者-PT 80选项。

-PT

扫描之前，使用TCP ping确定哪些主机正在运行。nmap不是通过发送ICMP echo请求包然后等待响应来实现这种功能，而是向目标网络(或者单一主机)发出TCP ACK包然后等待回应。如果主机正在运行就会返回RST包。只有在目标网络/主机阻塞了ping包，而仍旧允许你对其进行扫描时，这个选项才有效。对于非root用户，我们使用connect()系统调用来实现这项功能。使用-PT 来设定目标端口。默认的端口号是80，因为这个端口通常不会被过滤。

-PS

对于root用户，这个选项让nmap使用SYN包而不是ACK包来对目标主机进行扫描。如果主机正在运行就返回一个RST包(或者一个SYN/ACK包)。

-PI

设置这个选项，让nmap使用真正的ping(ICMP echo请求)来扫描目标主机是否正在运行。使用这个选项让nmap发现正在运行的主机的同时，nmap也会对你的直接子网广播地址进行观察。直接子网广播地址一些外部可达的IP地址，把外部的包转换为一个内向的IP广播包，向一个计算机子网发送。这些IP广播包应该删除，因为会造成拒绝服务攻击(例如smurf)。

-PB

这是默认的ping扫描选项。它使用ACK(-PT)和ICMP(-PI)两种扫描类型并行扫描。如果防火墙能够过滤其中一种包，使用这种方法，你就能够穿过防火墙。

-O

这个选项激活对TCP/IP指纹特征(fingerprinting)的扫描，获得远程主机的标志。换句话说，nmap使用一些技术检测目标主机操作系统网络协议栈的特征。nmap使用这些信息建立远程主机的指纹特征，把它和已知的操作系统指纹特征数据库做比较，就可以知道目标主机操作系统的类型。

-I

这个选项打开nmap的反向标志扫描功能。Dave Goldsmith 1996年向bugtap发出的邮件注意到这个协议，ident协议(rfc 1413)允许使用TCP连接给出任何进程拥有者的用户名，即使这个进程并没有初始化连接。例如，你可以连接到HTTP端口，接着使用identd确定这个服务器是否由root用户运行。这种扫描只能在同目标端口建立完全的TCP连接时(例如：-sT扫描选项)才能成功。使用-I选项是，远程主机的identd精灵进程就会查询在每个打开的端口上监听的进程的拥有者。显然，如果远程主机没有运行identd程序，这种扫描方法无效。

-f

这个选项使nmap使用碎片IP数据包发送SYN、FIN、XMAS、NULL。使用碎片数据包增加包过滤、入侵检测系统的难度，使其无法知道你的企图。不过，要慎重使用这个选项！有些程序在处理这些碎片包时会有麻烦，我最喜欢的嗅探器在接受到碎片包的头36个字节时，就会发生segmentation faulted。因此，在nmap中使用了24个字节的碎片数据包。虽然包过滤器和防火墙不能防这种方法，但是有很多网络出于性能上的考虑，禁止数据包的分片。

注意这个选项不能在所有的平台上使用。它在Linux、FreeBSD、OpenBSD以及其它一些UNIX系统能够很好工作。

-v

冗余模式。强烈推荐使用这个选项，它会给出扫描过程中的详细信息。使用这个选项，你可以得到事半功倍的效果。使用-d选项可以得到更加详细的信息。

-h

快速参考选项。

-oN

把扫描结果重定向到一个可读的文件logfilename中。

-oM

把扫描结果重定向到logfilename文件中，这个文件使用主机可以解析的语法。你可以使用-oM -来代替logfilename，这样输出就被重定向到标准输出stdout。在这种情况下，正常的输出将被覆盖，错误信息荏苒可以输出到标准错误stderr。要注意，如果同时使用了-v选项，在屏幕上会打印出其它的信息。

-oS thIs l0gz th3 r3suLtS of YouR ScanZ iN a s| THe fiL3 U sPecfy 4s an arGuMEnT! U kAn gIv3 the 4rgument -

(wItHOUt qUOteZ) to sh00t output iNT0 stDouT!@!! 莫名其妙，下面是我猜着翻译的，相形字？

把扫描结果重定向到一个文件logfilename中，这个文件使用一种"黑客方言"的语法形式(作者开的玩笑?)。同样，使用-oS -就会把结果重定向到标准输出上。

-resume

某个网络扫描可能由于control-C或者网络损失等原因被中断，使用这个选项可以使扫描接着以前的扫描进行。logfilename是被取消扫描的日志文件，它必须是可读形式或者机器可以解析的形式。而且接着进行的扫描不能增加新的选项，只能使用与被中断的扫描相同的选项。nmap会接着日志文件中的最后一次成功扫描进行新的扫描。

-iL

从inputfilename文件中读取扫描的目标。在这个文件中要有一个主机或者网络的列表，由空格键、制表键或者回车键作为分割符。如果使用-iL -，nmap就会从标准输入stdin读取主机名字。你可以从指定目标一节得到更加详细的信息。

-iR

让nmap自己随机挑选主机进行扫描。

-p

这个选项让你选择要进行扫描的端口号的范围。例如，-p 23表示：只扫描目标主机的23号端口。-p 20-30,139,60000-表示：扫描20到30号端口，139号端口以及所有大于60000的端口。在默认情况下，nmap扫描从1到1024号以及nmap-services文件(如果使用RPM软件包，一般在/usr/share/nmap/目录中)中定义的端口列表。

-F

快速扫描模式，只扫描在nmap-services文件中列出的端口。显然比扫描所有65535个端口要快。

-D

使用诱饵扫描方法对目标网络/主机进行扫描。如果nmap使用这种方法对目标网络进行扫描，那么从目标主机/网络的角度来看，扫描就象从其它主机(decoy1,等)发出的。从而，即使目标主机的IDS(入侵检测系统)对端口扫描发出报警，它们也不可能知道哪个是真正发起扫描的地址，哪个是无辜的。这种扫描方法可以有效地对付例如路由跟踪、response-dropping等积极的防御机制，能够很好地隐藏你的IP地址。

每个诱饵主机名使用逗号分割开，你也可以使用ME选项，它代表你自己的主机，和诱饵主机名混杂在一起。如果你把ME放在第六或者更靠后的位置，一些端口扫描检测软件几乎根本不会显示你的IP地址。如果你不使用ME选项，nmap会把你的IP地址随机夹杂在诱饵主机之中。

注意:你用来作为诱饵的主机应该正在运行或者你只是偶尔向目标发送SYN数据包。很显然，如果在网络上只有一台主机运行，目标将很轻松就会确定是哪台主机进行的扫描。或许，你还要直接使用诱饵的IP地址而不是其域名，这样诱饵网络的域名服务器的日志上就不会留下关于你的记录。

还要注意：一些愚蠢的端口扫描检测软件会拒绝路由试图进行端口扫描的主机。因而，你需要让目标主机和一些诱饵断开连接。如果诱饵是目标主机的网关或者就是其自己时，会给目标主机造成很大问题。所以你需要慎重使用这个选项。

诱饵扫描既可以在起始的ping扫描也可以在真正的扫描状态下使用。它也可以和-O选项组合使用。

使用太多的诱饵扫描能够减缓你的扫描速度甚至可能造成扫描结果不正确。同时，有些ISP会把你的欺骗包过滤掉。虽然现在大多数的ISP不会对此进行限制。

-S

在一些情况下，nmap可能无法确定你的源地址(nmap会告诉你)。在这种情况下，可以使用这个选项给出你的IP地址。

在欺骗扫描时，也使用这个选项。使用这个选项可以让目标认为是其它的主机对自己进行扫描。

-e

告诉nmap使用哪个接口发送和接受数据包。nmap能够自动对此接口进行检测，如果无效就会告诉你。

-g

设置扫描的源端口。一些天真的防火墙和包过滤器的规则集允许源端口为DNS(53)或者FTP-DATA(20)的包通过和实现连接。显然，如果攻击者把源端口修改为20或者53，就可以摧毁防火墙的防护。在使用UDP扫描时，先使用53号端口；使用TCP扫描时，先使用20号端口。注意只有在能够使用这个端口进行扫描时，nmap才会使用这个端口。例如，如果你无法进行TCP扫描，nmap会自动改变源端口，即使你使用了-g选项。

对于一些扫描，使用这个选项会造成性能上的微小损失，因为我有时会保存关于特定源端口的一些有用的信息。

-r

告诉nmap不要打乱被扫描端口的顺序。

--randomize_hosts

使nmap在扫描之前，打乱每组扫描中的主机顺序，nmap每组可以扫描最多2048台主机。这样，可以使扫描更不容易被网络监视器发现，尤其和--scan_delay 选项组合使用，更能有效避免被发现。

-M

设置进行TCP connect()扫描时，最多使用多少个套接字进行并行的扫描。使用这个选项可以降低扫描速度，避免远程目标宕机。

简述全连接扫描的基本原理 如何连接扫描主机

1、全连接扫描是TCP端口扫描的基础，现有的全连接扫描有TCP connect()扫描和TCP反向ident扫描等。

2、扫描主机通过TCP/IP协议的三次握手与目标主机的指定端口建立一次完整的连接。连接由系统调用connect开始。如果端口开放，则连接将建立成功；否则，若返回-1则表示端口关闭。建立连接成功：响应扫描主机的SYN/ACK连接请求，这一响应表明目标端口处于监听(打开)的状态。如果目标端口处于关闭状态，则目标主机会向扫描主机发送RST的响应。

描述使用Nmap对系统进行网络端口扫描的过程

【实验过程]】

将实验指导书的实验过程缩写，重点在于写出实验执行的具体步骤，以下是一个实验的书写实例：

1、 运行实验工具目录下的Nmap安装程序，安装Nmap到系统中的默认路径

2、 主机发现：运行如下命令：Nmap –sP 192.168.80.201，来判断目标主机Windows

Server A是否可连通

3、 使用常规扫描方式对目标主机进行TCP端口扫描，运行如下命令：Nmap –sT

192.168.80.201

4、 使用SYN半扫描方式，对目标主机进行TCP端口扫描，运行如下命令：Nmap –sS

192.168.80.201

5、 对主机进行UDP端口扫描，运行如下命令：Nmap –sV 192.168.80.201

6、 探测目标主机的操作系统类型，运行如下命令：Nmap –O –P0 192.168.80.201

7、 运行Namp的图形化前端程序Nmap，在“Target”中输入扫描目标的IP地址

（192.168.80.201），然后在Profile预定义配置下拉框中选择配置“Intense Scan ， no Ping”，然后点击菜单项“Profile”-“Edit Selected Profile”，切换到“Scan”选项卡，勾选上“Operation system detection”和“Version detection”，然后点击“Save Changes”按钮保存扫描配置，最后点击“Scan”按钮开始扫描。

具体参考

TCP/IP三次握手具体过程？

一、TCP握手协议

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：

未连接队列：在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。

Backlog参数：表示未连接队列的最大容纳数目。

SYN-ACK 重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。

半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。