10 个解决方案
#1
TCP吗？执行“telnet 127.0.0.1 5000”
#2
是啊，如何在VC中实现啊？请教
#3
看来这位兄弟的网络课程没有学好，是不是在上课的时候只记者偷看前面的美女了？TCP有一个三次握手，就是利用这个可以探测是否打开了端口，具体的实现自己去查一下，这样的源代码很多的，端口扫描程序也是很多。
#4
bind端口不成功，已经被占用
connect端口成功，该端口正在listen
connect端口成功，该端口正在listen
#5
connect
#6
tcp用 connect
udp可向该端口发一任意数据，若是开着的(即正在recvfrom)，则无ICMP消息返回，若收到ICMP消息，则没有打开。
这不是教你端口扫描吗~~~~~~~~~~
udp可向该端口发一任意数据，若是开着的(即正在recvfrom)，则无ICMP消息返回，若收到ICMP消息，则没有打开。
这不是教你端口扫描吗~~~~~~~~~~
#7
TCP安全一点的话，可以用半打开扫描
#8
UDP那样做不能保证100%成功。因为它的传输不可靠
#9
UDP的connect函数
除非套接口已连接，否则异步错误是不会返回到UDP套接口的。实际上，我们可以给UDP套接口调用connect，但这样做的结果却与TCP连接毫不相同，没有三路握手过程。内核只是记录对方的IP地址和端口号，它们包含在传递给connect的套接口地址结梅中，并立即返回给调用进程。
给connect函数重载(overload)UDP套接口的这种能力容易让人混淆。如果使用约定：sockname是本地协议地址，而peername是远程协议地址，则更好的名字可能是setpeername。类似地，函数bind的更好名字也许是setsockname。
有了这个能力后，我们必须区分；
·未连接UDP套接口(unconnected UDP socket)，当我们创建UDP套接口时，缺省为此；
·已连接UDP套接口(connected UDP socket)，对UDP套接口调用connect的结果。
对于已连接UDP套接口，与缺省的未连接UDP套接口相比，发生了三个变化：
1．我们再也不能给输出操作指定目的IP地址和端口号。也就是说，我们不使用sendto，而使用write或send。写到已连接UDP套接口上的任何东西都自动发送到由connect所指定的协议地址(例如IP地址和端口号)。
与TCP相似，我们可以给已连接UDP套接口调用sendto，但不能指定目的地址。sendto的第五个参数(指向套接口地址结构的指针)必须为空指针，第六个参数(套接口地址结构的大小)应为0。Posix.1g规定，当第五个参数是空指针时，就不再考虑第六个参数的取值情况。
2．我们不用recvfrom而用read或recv。在已连接UDP套接口上由内核为输入操作返回的唯一数据报是那些来自connect所指定协议地址的数据报。目的地址为已连接UDP套接口的本地协议地址(例如IP地址和端口号)，但不是从connect所指定套接口协议地址到达的数据报，不传递给已连接套接口。这就限制了已连接UDP套接口能且只能与一个对方交换数据报。严格地说，一个已连接UDP套接口仅与一个IP地址交换数据报，因为connect到多播或广播地址是可能的。
3．异步错误由已连接UDP套接口返回给进程，由此推断，未连接UDP套接口不接收任何异步错误，这在前面我们已描述过。
图8．14就4．4BSD总结了上面列表中第一点。
┌─────────┬───────┬───────┬──────────┐
│ │ │不指定目的 │ │
│套接口类型 │write 或 send │地址的 sendto │指定目的地址 sendto │
├─────────┼───────┼───────┼──────────┤
│TCP 套接口 │ 可以 │可以 │ EISCONN │
├─────────┼───────┼───────┼──────────┤
│UDP 套接口，已连接│ 可以 │可以 │ EISCONN │
│UDP 套接口，未连接│EDESTADDRREQ │EDESTADDRREQ │ 可以 │
└─────────┴───────┴───────┴──────────┘
图8．14 TCP和UDP套接口：可指定目的协议地址吗？
POSIX.1g指出，在未连接UDP套接口上不指定目的地址的输出操作应返回ENOTCONN，而不是EDESTADDRREQ。
Solaris 2．5允许sendto给已连接UDP套接口指定目的地址，而Posix.lg规定应返回EISCONN。
图8．15就我们给已连接UDP套接口所归纳的三点做了一个小结。
┌─────┐ ┌─────┐
│ 应用进程 │ │ 对方进程 │
└──┬┬─┘ └──┬┬─┘
read↑↓write ↑↓
┌──┴┴─┐从connect存储对方 ┌──┴┴─┐
???←─┤UDP ││ │的IP地址和端口号 │UDP ││ │
└┬─┬┬─┘ └──┬┬─┘
↑ ↑↓ UDP 数据报 ↑│
──────────→┘ │└────────────────→┘↓
来自于其他IP地址和/或 └←──────────────────┘
端口号的UDP数据报 UDP数据报
图8．15已连接UDP套接口
应用进程调用connect，指定对方的IP地址和端口号，然后用read和write来与对方交换数据。
从任何其他IP地址或端口(图8．15中我们用“???”表示)到达的数据报不递送给已连接套接口，因为要么源IP地址要么源UDP端口不与所连接的套接口协议地址相匹配。这些数据报可能递送给同一主机上的其他UDP套接口。如果到达的数据报没有其他匹配的套接口，UDP将丢弃它并生成一个ICMP端口不可达错误。
作为小结，仅在进程用UDP套接口与确定的唯一对方进行通信时，UDP客户或服务器才可以调用connect。一般来说，都是UDP客户调用connect，但也有UDP服务器与单个客户长时间通信的应用程序(如TFTP)，这种情况下，客户和服务器都可调用connect。
DNS提供了另一个例子，如图8．16所示。
┌────┐ ┌────┐ ┌────┐ ┌────┐
│ DNS ├───→│ DNS ├───→│ DNS ├───→│ DNS │
│ 客户 │←───┤ 服务器 │←───┤ 客户 │←───┤ 服务器 │
└────┘ └────┘ └────┘ └────┘
connect成功 不能connect 不能connect 不能connect
(被配置成只使 (被配置成使用
用一个服务器) 两个服务器)
图8．16 DNS客户、服务器与函数connect的例子
通过在文件/etc/resolv.conf中列出服务器的IP地址，DNS客户可被配置为使用一个或多个服务器。如果列出单个服务器(图中最左边的方框)，客户可以调用connect，但如果列出多个服务器(图中从右边数第二个方框)，客户就不能调用connect。而且，DNS服务器通常是处理任何客户的请求，所以服务器不能调用connect。
除非套接口已连接，否则异步错误是不会返回到UDP套接口的。实际上，我们可以给UDP套接口调用connect，但这样做的结果却与TCP连接毫不相同，没有三路握手过程。内核只是记录对方的IP地址和端口号，它们包含在传递给connect的套接口地址结梅中，并立即返回给调用进程。
给connect函数重载(overload)UDP套接口的这种能力容易让人混淆。如果使用约定：sockname是本地协议地址，而peername是远程协议地址，则更好的名字可能是setpeername。类似地，函数bind的更好名字也许是setsockname。
有了这个能力后，我们必须区分；
·未连接UDP套接口(unconnected UDP socket)，当我们创建UDP套接口时，缺省为此；
·已连接UDP套接口(connected UDP socket)，对UDP套接口调用connect的结果。
对于已连接UDP套接口，与缺省的未连接UDP套接口相比，发生了三个变化：
1．我们再也不能给输出操作指定目的IP地址和端口号。也就是说，我们不使用sendto，而使用write或send。写到已连接UDP套接口上的任何东西都自动发送到由connect所指定的协议地址(例如IP地址和端口号)。
与TCP相似，我们可以给已连接UDP套接口调用sendto，但不能指定目的地址。sendto的第五个参数(指向套接口地址结构的指针)必须为空指针，第六个参数(套接口地址结构的大小)应为0。Posix.1g规定，当第五个参数是空指针时，就不再考虑第六个参数的取值情况。
2．我们不用recvfrom而用read或recv。在已连接UDP套接口上由内核为输入操作返回的唯一数据报是那些来自connect所指定协议地址的数据报。目的地址为已连接UDP套接口的本地协议地址(例如IP地址和端口号)，但不是从connect所指定套接口协议地址到达的数据报，不传递给已连接套接口。这就限制了已连接UDP套接口能且只能与一个对方交换数据报。严格地说，一个已连接UDP套接口仅与一个IP地址交换数据报，因为connect到多播或广播地址是可能的。
3．异步错误由已连接UDP套接口返回给进程，由此推断，未连接UDP套接口不接收任何异步错误，这在前面我们已描述过。
图8．14就4．4BSD总结了上面列表中第一点。
┌─────────┬───────┬───────┬──────────┐
│ │ │不指定目的 │ │
│套接口类型 │write 或 send │地址的 sendto │指定目的地址 sendto │
├─────────┼───────┼───────┼──────────┤
│TCP 套接口 │ 可以 │可以 │ EISCONN │
├─────────┼───────┼───────┼──────────┤
│UDP 套接口，已连接│ 可以 │可以 │ EISCONN │
│UDP 套接口，未连接│EDESTADDRREQ │EDESTADDRREQ │ 可以 │
└─────────┴───────┴───────┴──────────┘
图8．14 TCP和UDP套接口：可指定目的协议地址吗？
POSIX.1g指出，在未连接UDP套接口上不指定目的地址的输出操作应返回ENOTCONN，而不是EDESTADDRREQ。
Solaris 2．5允许sendto给已连接UDP套接口指定目的地址，而Posix.lg规定应返回EISCONN。
图8．15就我们给已连接UDP套接口所归纳的三点做了一个小结。
┌─────┐ ┌─────┐
│ 应用进程 │ │ 对方进程 │
└──┬┬─┘ └──┬┬─┘
read↑↓write ↑↓
┌──┴┴─┐从connect存储对方 ┌──┴┴─┐
???←─┤UDP ││ │的IP地址和端口号 │UDP ││ │
└┬─┬┬─┘ └──┬┬─┘
↑ ↑↓ UDP 数据报 ↑│
──────────→┘ │└────────────────→┘↓
来自于其他IP地址和/或 └←──────────────────┘
端口号的UDP数据报 UDP数据报
图8．15已连接UDP套接口
应用进程调用connect，指定对方的IP地址和端口号，然后用read和write来与对方交换数据。
从任何其他IP地址或端口(图8．15中我们用“???”表示)到达的数据报不递送给已连接套接口，因为要么源IP地址要么源UDP端口不与所连接的套接口协议地址相匹配。这些数据报可能递送给同一主机上的其他UDP套接口。如果到达的数据报没有其他匹配的套接口，UDP将丢弃它并生成一个ICMP端口不可达错误。
作为小结，仅在进程用UDP套接口与确定的唯一对方进行通信时，UDP客户或服务器才可以调用connect。一般来说，都是UDP客户调用connect，但也有UDP服务器与单个客户长时间通信的应用程序(如TFTP)，这种情况下，客户和服务器都可调用connect。
DNS提供了另一个例子，如图8．16所示。
┌────┐ ┌────┐ ┌────┐ ┌────┐
│ DNS ├───→│ DNS ├───→│ DNS ├───→│ DNS │
│ 客户 │←───┤ 服务器 │←───┤ 客户 │←───┤ 服务器 │
└────┘ └────┘ └────┘ └────┘
connect成功 不能connect 不能connect 不能connect
(被配置成只使 (被配置成使用
用一个服务器) 两个服务器)
图8．16 DNS客户、服务器与函数connect的例子
通过在文件/etc/resolv.conf中列出服务器的IP地址，DNS客户可被配置为使用一个或多个服务器。如果列出单个服务器(图中最左边的方框)，客户可以调用connect，但如果列出多个服务器(图中从右边数第二个方框)，客户就不能调用connect。而且，DNS服务器通常是处理任何客户的请求，所以服务器不能调用connect。
#10
这个是《UNIX网络编程——套接口API和X/0pen传输接口API》的“第8章 基本UDP套接口编程”，关于UDP编程讲的非常详细，建议大家找一本这样的书好好学习，会有很多收获的。平时编程经常出现的误区可以得以解决。其它方面的内容也很有帮助的。
#1
TCP吗？执行“telnet 127.0.0.1 5000”
#2
是啊，如何在VC中实现啊？请教
#3
看来这位兄弟的网络课程没有学好，是不是在上课的时候只记者偷看前面的美女了？TCP有一个三次握手，就是利用这个可以探测是否打开了端口，具体的实现自己去查一下，这样的源代码很多的，端口扫描程序也是很多。
#4
bind端口不成功，已经被占用
connect端口成功，该端口正在listen
connect端口成功，该端口正在listen
#5
connect
#6
tcp用 connect
udp可向该端口发一任意数据，若是开着的(即正在recvfrom)，则无ICMP消息返回，若收到ICMP消息，则没有打开。
这不是教你端口扫描吗~~~~~~~~~~
udp可向该端口发一任意数据，若是开着的(即正在recvfrom)，则无ICMP消息返回，若收到ICMP消息，则没有打开。
这不是教你端口扫描吗~~~~~~~~~~
#7
TCP安全一点的话，可以用半打开扫描
#8
UDP那样做不能保证100%成功。因为它的传输不可靠
#9
UDP的connect函数
除非套接口已连接，否则异步错误是不会返回到UDP套接口的。实际上，我们可以给UDP套接口调用connect，但这样做的结果却与TCP连接毫不相同，没有三路握手过程。内核只是记录对方的IP地址和端口号，它们包含在传递给connect的套接口地址结梅中，并立即返回给调用进程。
给connect函数重载(overload)UDP套接口的这种能力容易让人混淆。如果使用约定：sockname是本地协议地址，而peername是远程协议地址，则更好的名字可能是setpeername。类似地，函数bind的更好名字也许是setsockname。
有了这个能力后，我们必须区分；
·未连接UDP套接口(unconnected UDP socket)，当我们创建UDP套接口时，缺省为此；
·已连接UDP套接口(connected UDP socket)，对UDP套接口调用connect的结果。
对于已连接UDP套接口，与缺省的未连接UDP套接口相比，发生了三个变化：
1．我们再也不能给输出操作指定目的IP地址和端口号。也就是说，我们不使用sendto，而使用write或send。写到已连接UDP套接口上的任何东西都自动发送到由connect所指定的协议地址(例如IP地址和端口号)。
与TCP相似，我们可以给已连接UDP套接口调用sendto，但不能指定目的地址。sendto的第五个参数(指向套接口地址结构的指针)必须为空指针，第六个参数(套接口地址结构的大小)应为0。Posix.1g规定，当第五个参数是空指针时，就不再考虑第六个参数的取值情况。
2．我们不用recvfrom而用read或recv。在已连接UDP套接口上由内核为输入操作返回的唯一数据报是那些来自connect所指定协议地址的数据报。目的地址为已连接UDP套接口的本地协议地址(例如IP地址和端口号)，但不是从connect所指定套接口协议地址到达的数据报，不传递给已连接套接口。这就限制了已连接UDP套接口能且只能与一个对方交换数据报。严格地说，一个已连接UDP套接口仅与一个IP地址交换数据报，因为connect到多播或广播地址是可能的。
3．异步错误由已连接UDP套接口返回给进程，由此推断，未连接UDP套接口不接收任何异步错误，这在前面我们已描述过。
图8．14就4．4BSD总结了上面列表中第一点。
┌─────────┬───────┬───────┬──────────┐
│ │ │不指定目的 │ │
│套接口类型 │write 或 send │地址的 sendto │指定目的地址 sendto │
├─────────┼───────┼───────┼──────────┤
│TCP 套接口 │ 可以 │可以 │ EISCONN │
├─────────┼───────┼───────┼──────────┤
│UDP 套接口，已连接│ 可以 │可以 │ EISCONN │
│UDP 套接口，未连接│EDESTADDRREQ │EDESTADDRREQ │ 可以 │
└─────────┴───────┴───────┴──────────┘
图8．14 TCP和UDP套接口：可指定目的协议地址吗？
POSIX.1g指出，在未连接UDP套接口上不指定目的地址的输出操作应返回ENOTCONN，而不是EDESTADDRREQ。
Solaris 2．5允许sendto给已连接UDP套接口指定目的地址，而Posix.lg规定应返回EISCONN。
图8．15就我们给已连接UDP套接口所归纳的三点做了一个小结。
┌─────┐ ┌─────┐
│ 应用进程 │ │ 对方进程 │
└──┬┬─┘ └──┬┬─┘
read↑↓write ↑↓
┌──┴┴─┐从connect存储对方 ┌──┴┴─┐
???←─┤UDP ││ │的IP地址和端口号 │UDP ││ │
└┬─┬┬─┘ └──┬┬─┘
↑ ↑↓ UDP 数据报 ↑│
──────────→┘ │└────────────────→┘↓
来自于其他IP地址和/或 └←──────────────────┘
端口号的UDP数据报 UDP数据报
图8．15已连接UDP套接口
应用进程调用connect，指定对方的IP地址和端口号，然后用read和write来与对方交换数据。
从任何其他IP地址或端口(图8．15中我们用“???”表示)到达的数据报不递送给已连接套接口，因为要么源IP地址要么源UDP端口不与所连接的套接口协议地址相匹配。这些数据报可能递送给同一主机上的其他UDP套接口。如果到达的数据报没有其他匹配的套接口，UDP将丢弃它并生成一个ICMP端口不可达错误。
作为小结，仅在进程用UDP套接口与确定的唯一对方进行通信时，UDP客户或服务器才可以调用connect。一般来说，都是UDP客户调用connect，但也有UDP服务器与单个客户长时间通信的应用程序(如TFTP)，这种情况下，客户和服务器都可调用connect。
DNS提供了另一个例子，如图8．16所示。
┌────┐ ┌────┐ ┌────┐ ┌────┐
│ DNS ├───→│ DNS ├───→│ DNS ├───→│ DNS │
│ 客户 │←───┤ 服务器 │←───┤ 客户 │←───┤ 服务器 │
└────┘ └────┘ └────┘ └────┘
connect成功 不能connect 不能connect 不能connect
(被配置成只使 (被配置成使用
用一个服务器) 两个服务器)
图8．16 DNS客户、服务器与函数connect的例子
通过在文件/etc/resolv.conf中列出服务器的IP地址，DNS客户可被配置为使用一个或多个服务器。如果列出单个服务器(图中最左边的方框)，客户可以调用connect，但如果列出多个服务器(图中从右边数第二个方框)，客户就不能调用connect。而且，DNS服务器通常是处理任何客户的请求，所以服务器不能调用connect。
除非套接口已连接，否则异步错误是不会返回到UDP套接口的。实际上，我们可以给UDP套接口调用connect，但这样做的结果却与TCP连接毫不相同，没有三路握手过程。内核只是记录对方的IP地址和端口号，它们包含在传递给connect的套接口地址结梅中，并立即返回给调用进程。
给connect函数重载(overload)UDP套接口的这种能力容易让人混淆。如果使用约定：sockname是本地协议地址，而peername是远程协议地址，则更好的名字可能是setpeername。类似地，函数bind的更好名字也许是setsockname。
有了这个能力后，我们必须区分；
·未连接UDP套接口(unconnected UDP socket)，当我们创建UDP套接口时，缺省为此；
·已连接UDP套接口(connected UDP socket)，对UDP套接口调用connect的结果。
对于已连接UDP套接口，与缺省的未连接UDP套接口相比，发生了三个变化：
1．我们再也不能给输出操作指定目的IP地址和端口号。也就是说，我们不使用sendto，而使用write或send。写到已连接UDP套接口上的任何东西都自动发送到由connect所指定的协议地址(例如IP地址和端口号)。
与TCP相似，我们可以给已连接UDP套接口调用sendto，但不能指定目的地址。sendto的第五个参数(指向套接口地址结构的指针)必须为空指针，第六个参数(套接口地址结构的大小)应为0。Posix.1g规定，当第五个参数是空指针时，就不再考虑第六个参数的取值情况。
2．我们不用recvfrom而用read或recv。在已连接UDP套接口上由内核为输入操作返回的唯一数据报是那些来自connect所指定协议地址的数据报。目的地址为已连接UDP套接口的本地协议地址(例如IP地址和端口号)，但不是从connect所指定套接口协议地址到达的数据报，不传递给已连接套接口。这就限制了已连接UDP套接口能且只能与一个对方交换数据报。严格地说，一个已连接UDP套接口仅与一个IP地址交换数据报，因为connect到多播或广播地址是可能的。
3．异步错误由已连接UDP套接口返回给进程，由此推断，未连接UDP套接口不接收任何异步错误，这在前面我们已描述过。
图8．14就4．4BSD总结了上面列表中第一点。
┌─────────┬───────┬───────┬──────────┐
│ │ │不指定目的 │ │
│套接口类型 │write 或 send │地址的 sendto │指定目的地址 sendto │
├─────────┼───────┼───────┼──────────┤
│TCP 套接口 │ 可以 │可以 │ EISCONN │
├─────────┼───────┼───────┼──────────┤
│UDP 套接口，已连接│ 可以 │可以 │ EISCONN │
│UDP 套接口，未连接│EDESTADDRREQ │EDESTADDRREQ │ 可以 │
└─────────┴───────┴───────┴──────────┘
图8．14 TCP和UDP套接口：可指定目的协议地址吗？
POSIX.1g指出，在未连接UDP套接口上不指定目的地址的输出操作应返回ENOTCONN，而不是EDESTADDRREQ。
Solaris 2．5允许sendto给已连接UDP套接口指定目的地址，而Posix.lg规定应返回EISCONN。
图8．15就我们给已连接UDP套接口所归纳的三点做了一个小结。
┌─────┐ ┌─────┐
│ 应用进程 │ │ 对方进程 │
└──┬┬─┘ └──┬┬─┘
read↑↓write ↑↓
┌──┴┴─┐从connect存储对方 ┌──┴┴─┐
???←─┤UDP ││ │的IP地址和端口号 │UDP ││ │
└┬─┬┬─┘ └──┬┬─┘
↑ ↑↓ UDP 数据报 ↑│
──────────→┘ │└────────────────→┘↓
来自于其他IP地址和/或 └←──────────────────┘
端口号的UDP数据报 UDP数据报
图8．15已连接UDP套接口
应用进程调用connect，指定对方的IP地址和端口号，然后用read和write来与对方交换数据。
从任何其他IP地址或端口(图8．15中我们用“???”表示)到达的数据报不递送给已连接套接口，因为要么源IP地址要么源UDP端口不与所连接的套接口协议地址相匹配。这些数据报可能递送给同一主机上的其他UDP套接口。如果到达的数据报没有其他匹配的套接口，UDP将丢弃它并生成一个ICMP端口不可达错误。
作为小结，仅在进程用UDP套接口与确定的唯一对方进行通信时，UDP客户或服务器才可以调用connect。一般来说，都是UDP客户调用connect，但也有UDP服务器与单个客户长时间通信的应用程序(如TFTP)，这种情况下，客户和服务器都可调用connect。
DNS提供了另一个例子，如图8．16所示。
┌────┐ ┌────┐ ┌────┐ ┌────┐
│ DNS ├───→│ DNS ├───→│ DNS ├───→│ DNS │
│ 客户 │←───┤ 服务器 │←───┤ 客户 │←───┤ 服务器 │
└────┘ └────┘ └────┘ └────┘
connect成功 不能connect 不能connect 不能connect
(被配置成只使 (被配置成使用
用一个服务器) 两个服务器)
图8．16 DNS客户、服务器与函数connect的例子
通过在文件/etc/resolv.conf中列出服务器的IP地址，DNS客户可被配置为使用一个或多个服务器。如果列出单个服务器(图中最左边的方框)，客户可以调用connect，但如果列出多个服务器(图中从右边数第二个方框)，客户就不能调用connect。而且，DNS服务器通常是处理任何客户的请求，所以服务器不能调用connect。
#10
这个是《UNIX网络编程——套接口API和X/0pen传输接口API》的“第8章 基本UDP套接口编程”，关于UDP编程讲的非常详细，建议大家找一本这样的书好好学习，会有很多收获的。平时编程经常出现的误区可以得以解决。其它方面的内容也很有帮助的。