网络编程中,网络建立连接成功后(网络编程题)
网络编程中,connect()什么时候结束啊?
TCP的连接建立需要进行3次握手,你可以百度下:“TCP3次握手”看看对这个更详细的说明。
所以connect就是做这样3个工作:
发出sync包(就是请求建立连接)
等待sync-ack包(就是服务器的响应,允许建立连接),对此要么是等到服务器的ack包,那么进行第3步,要么是收到服务器地址不可达或者返回端口不可用的错误或者是在规定时间内没有受到服务器的响应那么就超时,不论如何,后面的错误会导致connect错误返回
connect函数发出ack包,表明连接正式建立,然后函数正确返回
至于数据到底是客户端先发出还是服务器端先发出,是由应用决定的,也就是在connect之后发生的。所以跟connect没有关系。connect之后你是想要recv还是send,随便你。
您好 :我是刚刚向您提问的盆友,对于网络编程中我只是有一点不太通,只要明白这一点问题就迎刃而解了~
jsp提交表单,这些都是http协议来完成的,所以这个属于http协议,当然也算是有关联的了,http协议底层又是通过tcp/ip协议完成的哦
socket编程的话,你是说CS结构的程序是吧? 还是说bs结构的?cs结构的就是socket,如果是说网页里面上传,那就是bs结构的程序了,bs结构底层还是socket,只是更底层一些
北大青鸟java培训:网络编程的协议连接问题?
我们在前几期的文章中曾经给大家简单介绍了关于网络编程中不同协议的使用情况与运行的原理问题。
今天山东IT培训就继续来了解一下,关于网络编程中不同协议的状态连接问题。
1、为什么建立连接协议是三次握手,而关闭连接是四次挥手呢?这是因为服务端的LISTEN状态下的SOCKET收到SYN的请求连接时,可以把ACK和SYN(ACK起应答作用,而SYN起同步作用)放在一个报文里一起发送.但是关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送了,但是另一方未必所有的数据都全部发送完全了,所以可能不会立马关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方表示你同意现在关闭连接了,所以这里的2、ACK报文和FIN报文是分开发送的.为什么不能用两次握手进行连接?在三次握手中,总共需要完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已经准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认.现在把三次握手改成仅需要两次握手,是可能会发生死锁的.考虑计算机客户端和服务端之间的通信,假定客户端给服务端发送一个连接请求分组,服务端收到了这个分组,并发送了确认应答分组.按照两次握手的协定,服务端认为链接已经成功的建立了,可以开始发送数据分组.可是,客户端在服务端的应答分组在传输中被丢失的情况下,将不会知道服务端是否已准备好,不知道服务端建立什么样的序列号,客户端甚至会怀疑服务端是否收到自己的连接请求分组.在这种情况下,客户端认为连接还未建立成功,将忽略服务端发来的任何数据分组,只等待连接确认应答分组.而服务端在发出的数据分组超时后,重复发送同样的数据分组,就形成了死锁.3、为什么TIME_WAIT状态需要等2MSL后才能返回到CLOSED状态?什么是MSL?MSL即MaximumSegmentLifetime,也就是报文大生存时间.'MSL是任何报文段被丢弃前在网络内的长时间.'那么,2MSL也就是这个时间的两倍,当TCP连接完成四个报文段的交换时,主动关闭的一方将继续等待一定时间(2-4)分钟,即使两端的应用程序结束.4、为什么需要2MSL呢.一,虽然双方都同意关闭连接了,而且握手的四个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文.二,报文可能会被混淆,意思是说其他时候的连接可能会被当做本次的连接.当某个连接的一端处于TIME_WAIT状态时,该连接将不能再被使用.事实上,对于我们比较有现实意义的是,这个端口将不能再被使用.某个端口处于TIME_WAIT(其实应该是这个连接)状态时,这意味着这个TCP连接并没有断开(完全断开),那么.如果你bind这个端口,就会失败.对于服务器而言,如果服务器突然crash掉了,那么他将无法在2MSL内重新启动,因为bind会失败.解决这个问题的一个方法就是设置SOCKET的SO_REUSEADDR选项.这个选项意味着可以重用一个地址.当建立一个TCP连接时,服务端会继续用原有端口,同时用这个端口与客户端通信.而客户端默认情况下会使用一个随机端口与服务端的端口通信.有时候,为了服务端的安全性,我们需要对客户端进行验证,即限定某个IP的某个特定端口的客户端.客户端可以使用bind来使用特定的端口.对于服务端,当设置了SO_REUSEADDR选项时,它可以在2MSL内启动并listen成功.但是对于客户端,当使用bind并设置SO_REUSEADDR时,如果在2MSL内启动,虽然bind会成功,但是在windows平台上connect会失败.而在linux是哪个不存在这个问题.
虚拟网络编辑器中,勾选了将主机连接到此网络,但是应用成功之后,还是没有 是怎么回事
VMware Network Adapter VMnet1和VMnet8 被防火墙认定为未识别的网络,阻隔,无法使用端口映射,虚拟机的80端口无法传入,数据包只能出不能入。且公用网络被限制不能修改为家庭或工作网络。
解决办法:
1,进入注册表[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}],先导出做备份。
2,逐项查看其下的[项](0000,0001至00xx),看右边哪一项的[值]为:"DriverDesc"="VMware Virtual Ethernet Adapter for VMnet1"。
3,找到后,添加一个“DWORD”值(32位),名称为“*NdisDeviceType”(*号是必须的),数据值改为“1”。
4,同理再找 VMnet8 ,再重复第2~3步,添加值。
java 网络编程: 如何实现客户端与客户端之间的之间通信
服务器告知双方对方的ip地址,并协调由哪一方主动连接。
如 协调结果是: 把c2的地址告诉c1,让c1主动连接c2,让c2打开端口等待连接。
要考虑认证问题,比如c2如何知道连接上来的是c1,而不是其他人,就需要有认证机制。
另外要考虑内网问题。由于从外部连接内网里面的IP地址是相当繁琐复杂的,所以需要特别的机制处理。
Unity网络编程(一)常见概念
一直用Http用多了 复习一下基础
Unity通讯一般分为2类
Http : 应用层 Unity内置的UnityWebRequest类进行通信(之前写过一个分发器垃圾框架)用于交互量比较小
Socket:传输层 比较底层 实现TCP/UDP 用于频繁的通信
这个是基于TCP 和IP传输不同消息
这个是三种常见的网络层次划分
基本数据单位为帧
主要的协议:以太网协议
基本数据单位为IP数据报;
IP协议(Internet Protocol,因特网互联协议)
ICMP协议(Internet Control Message Protocol,因特网控制报文协议)
ARP协议(Address Resolution Protocol,地址解析协议)
RARP协议(Reverse Address Resolution Protocol,逆地址解析协议)
包含的主要协议:TCP协议(Transmission Control Protocol,传输控制协议)、UDP协议(User Datagram Protocol,用户数据报协议)
数据传输基本单位为报文
包含的主要协议:
FTP(文件传送协议)、Telnet(远程登录协议)、DNS(域名解析协议)、SMTP(邮件传送协议),POP3协议(邮局协议),HTTP协议(Hyper Text Transfer Protocol)。
分配给用户上网使用的网际协议
目前IPv4多 比如192.168.1.1
新的IPv6(因为IPv4数量不够分配)如3ffe:3201:1401:1280:c8ff:fe4d:db39:1984。
Internet最基本的协议
TCP负责发现传输的问题,一有问题就发出信号,要求重新传输,直到所有数据安全正确地传输到目的地。
可靠的协议 通过三次握手建立的面向连接通信协议
3次握手 四次挥手 实习生常考
TCP连接建立过程(三次握手):
1.首先Client端发送连接请求报文
2.Server段接受连接后回复ACK报文,并为这次连接分配资源。
3.Client端接收到ACK报文后也向Server段发生ACK报文,并分配资源,这样TCP连接就建立了。
TCP连接断开过程(四次挥手):
1.Client端发起中断连接请求(FIN报文)
2.Server端接到FIN报文后,发送ACK服务器还有消息没发完让Client待命,Client端就进入FIN_WAIT,继续等待Server端的FIN报文
3.Server端确定数据已发送完成,则向Client端发送FIN报文,
4.Client端收到FIN报文后发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传,Server端收到ACK后 关闭,Client等待了2MSL后依然没有收到回复客户端也关闭
SYN:"synchronize"请求同步标志;;ACK:"acknowledge"确认标志";FIN:"Finally"结束标志。
为什么要三次握手?
防止因为网卡导致Sever收到多次Client请求 建立N个监听 造成资源浪费
为什么要四次挥手?
自己不请求直接关闭 但是服务器还能给你发数据 服务器浪费资源 而且客户端也会强行接收
使用TCP的协议:FTP(文件传输协议)、Telnet(远程登录协议)、SMTP(简单邮件传输协议)、POP3(和SMTP相对,用于接收邮件)、HTTP协议等。
面向无连接的通讯协议
UDP通讯时不需要接收方确认,属于不可靠的传输 会丢包
UDP与TCP位于同一层,但它不管数据包的顺序、错误或重发
主要用于面向查询---应答的程序
每个UDP报文分UDP报头和UDP数据区两部分
UDP报头由4个域组成,其中每个域各占用2个字节
(1)源端口号;
(2)目标端口号;
(3)数据报长度;
(4)校验值。
使用UDP协议包括:TFTP(简单文件传输协议)、SNMP(简单网络管理协议)、DNS(域名解析协议)、NFS、BOOTP。
超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议
HTTP协议特点:
简单快速 灵活 无连接 无状态 支持B/S(浏览器/服务器)及C/S(客户端/服务器)模式。
URL
和服务器有一些频繁的交互 用http时不时请求 叫轮询 效率低下
soket可以理解为插座 插头接上了可以保持通信
端口:
每个Socket连接都是从一台计算机网卡的一个端口连接到另外一台计算机网卡的某个端口。
IP是房子的话 端口就是门
TCP端口和UDP端口相互独立 如TCP255端口 和UDP255端口 不冲突
周知端口
范围从0到1023,其中80端口分配给WWW服务,21端口分配给FTP服务等。
浏览器的地址栏里输入一个网址的时候是不必指定端口号的,因为在默认情况下WWW服务的端口是“80”。
网络服务是可以使用其他端口号的 比如 网址:8080
但是有些系统协议使用固定的端口号,它是不能被改变的,比如139 端口专门用于NetBIOS与TCP/IP之间的通信,不能手动改变。
自己开发时尽量不要使用1024之下的端口,可能会与系统端口冲突。
服务端:
创建socket对象
bind:绑定IP地址和端口
listen:开始监听绑定的IP地址和端口,等待客户端的连接
accept:如果有客户端发起连接,通过accept接受连接请求,连接成功后会复制一个socket出来用于和当前接受连接的客户端进行通信。(服务端最初创建的那个socket只是用来监听并建立连接用的,实际和客户端通信并不是最初的socket,而是在accept这一步会自动创建一个新的socket出来和客户端通信。)
read/write:使用新的socket读写数据
close:关闭socket,如果关闭的是服务端的监听socket,则无法接收新的连接,但是已经创建的和客户端的连接不会被关闭。
客户端:
创建socket对象
connect:连接服务端,连接成功后系统会自动分配端口
read/write:连接成功后,就可以进行数据的读写了,这里读写使用的socket还是第一步创建的socket对象。
close:关闭连接。
如果收到了长度为0的数据,则代表远程socket关闭了连接。
服务器:
创建socket对象
bind:绑定IP和端口,用于接收数据(注意这里绑定完就可以直接接收数据了,并不需要等待连接)
read/write:读写数据
客户端:
创建socket对象
read/write:读写数据,不需要先建立连接,直接给对应的IP+端口发送数据即可。
由于没有建立连接以及连接的保障,UDP在传输效率上会很高
UDP有一个功能是TCP所不具备的,那就是广播功能(UDP可以将消息发送到在同一广播网络上的每个主机 CS、魔兽争霸局域网对战)。
HTTP/HTTPS(比http更安全):小游戏 网页 间歇性发送链接 偶尔延迟。
TCP长连接: 卡牌游戏 某些mmo 客户端和服务器都可以独立发包 偶尔延迟
UDP:动作游戏 mmo 枪战 客户端和服务器都可以独立发包 无法接受延迟
可以混合使用你的MMO客户端也许首先使用HTTP去获取上一次的更新内容,然后使用UDP跟游戏服务器进行连接。
现在也有kcp 就是tcp和udp结合 快速安全可靠
简单直接的长连接
可靠的信息传输
数据包的大小没有限制
坑多 断线检测、慢速客户端响应阻塞数据包,对开放连接的各种dos攻击,阻塞和非阻塞IO模型
丢包会有阻塞机制(一般是重发 tcp相反) 所以手机游戏ping跳1000就这个原因
只使用一个socket进行通信
快速
基于数据包构建
灵活 多种方式处理延迟
很多东西没有要自己构建
不可靠
丢包
客户端直接开始进行计算而不等待服务端确认是一种典型的隐藏延迟的技术(容易被抓包篡改)。
我们到底是使用TCP还是UDP取决于我们能否隐藏延迟。
比如TCP 在棋牌 卡牌游戏 卡1S无所谓 在动作游戏moba游戏就很致命
可靠的UDP/kcp和TCP不一样,要去实现一个特殊的阻塞控制,而且还要保证可靠性,也可以使用许多支持可靠通信的UDP库,但是库一般为了通用会降低某种新能,自己根据项目情况写可以发挥到极致
如果不知道用什么就TCP