2两个问题

服务器端口号ftp21ssh22telnet23http80https443

vim

端口号是用来标识主机内进程的唯一性所以一个端口号是不能被多个进程bind的

会通过一个hash表(储存着bind进程与端口号的映射)找到对应的进程

但如果bind进程映射的端口号不是唯一的还有其它bind进程也与该端口号进行关联

端口号在进行配对时就不确定是哪个进程了(hash冲突)所以这样就说明了端口号是不能bind多个进程的

二UDP协议

报文中有16位目的端口号当主机收到UDP报文时读取源端口后进行查表(bind的进程对应的端口号)找到指定进程再填写端口号就能进行通信了

2特点

我们在使用UDP协议时进行反序列化让结构体转成字符串再以网络序列发送出去对方在接收时也是按照这个结构体来进行反序列化这个过程是在内核中规定好了的

双方在进行通信时设备可能完全不一样编写语言不同大小端内存对齐...

而在操作系统内核中能这么干双方内核都是C语言写的不会引进其它新的结构体字段网络序列基本是固定的只要考虑好大小端问题就OK了

3.2关于报文

在OS中可能在某一时间段内有很多的报文一些有可能要向上交付一些要向下交付一些可能发生失败要进行丢弃...而OS要对这些报文进行管理如何管理先描述在组织

sk_buff

在协议栈中往下交付时其实传的是sk_buff指针*head往左移:添加报文(封包)

NFS网络文件系统TFTP简单文件传输协议DHCP动态主机配置协议BOOTP启动协议(用于无盘设备启动)DNS域名解析协议

三TCP协议

如果报头大小为20字节那么4位首部长度为0101(20/45)

1.提取20字节(报头大小)

不为0则有选项(选项首部长度-报头大小)(假设选项大小为16)提取16字节:剩下的都是数据

b如何分用

发送TCP前我们要先填16位目的端口(发送给谁)对方收到后报头里的16位源端口代表谁发送的读取它并把它往上交付给指定的进程便能进行通信了

举一个例子当你给朋友发微信你吃了吗过了一会朋友回你还没吃朋友进行了回复就说明他一定是送到了我发给他的消息否则就不会无缘无故会发信息说还没吃

当client发送报文给server后server有应答那我们就认为serer一定是收到了报文

(但总会有最新的消息还没有应答这个我们不保证:对方收到了应答就说明历史数据被对方收到了

对于clinet来讲

有没有可能收不到应答的情况是有可能的(有可能是发出去的数据丢失也可能是server的应答丢失)但这种情况我们都认为报文丢失了

收到应答100%就认为server收到报文反之报文丢失(后面说)这便是TCP协议的可靠性

TCP也是全双工的那么server到client(反过来)也是保证可靠性的思路与上面类似

第一种一个报文一个报文的发送类似你去快递站一个快递拿回家拆完后又去快递站拿

另一种是(在某个时间段)同时发送多个报文同时送到多个应答报文(TCP常用的通信方式)

确认应答中1001数字是填在应答报文的确认序号里即代表1001之前的数据已经全部收到

那这时有人要问了把发送过来的报文里的32位序号修改成1001不就行了吗?为什么要有两个序号

要记住TCP时全双工的server也有可能给client发报文(数据)此时历史数据也要给client发应答报文难道server要发两个报文

server可以在一个报文里填上两个序号来代表我既要给你发数据也要对临时数据作应答这种方式叫做捎带应答提高了发送效率

我们知道发送数据本质是发送到对方的发送缓冲区中我们从逻辑上把缓冲区中的字节流看成是数组的形式(实际比较复杂)那么序列号的填写工作不就是转换成最后一个值的数字下标吗

而在TCP中client发送的报文请求每次可能是不同的有建立连接的发送数据的断开连接的应答的应答发送数据的server怎么知道收到的报文是什么请求(类型)呢

通过报头里的保留(6位)的标记位来进行判断ack标记为1说明该报文时应答报文该报文里有数据说明该报文类型是应答

发送数据类型

共有两种情况主机A发送数据时丢包和主机B应答时丢包这时就会触发TCP的超时重传机制在特定的时间间隔内重新发送数据

TCP判定两个报文序号一样会去重

那如果主机B收到了很多报文要对报文进行判别那个是先到那个是后到的又怎么办

这就要取决于网络状态了网络好时间间隔短网络差时间间隔长在500ms整数倍浮动

4连接管理

但我们在平时写TCP代码是只有listenacceptconnect根本就没有这种感觉这其实是OS在内部帮助我们在做~

4.1建立连接

建立连接这件事就好比男女确定男女关系一样男做我女朋友好吗女好啊那你做我男朋友好吗

男好啊

我们在前面说了TCP只保证历史数据被对方收到了不保证最新的数据被对方收到那么最后一次握手时client给serverACK时不是就可能出现丢包的情况吗怎么解决这个问题

如果在最后一次出现丢包了server是不知道这回事的它会以为连接以及建立好了接下来就给server发送数据但server收到数据后在想连接不是还没建立好吗怎么这么快就给我发消息哦我明白了出现丢包了所以server会给client发送报头中把reset标记位置1来告诉server连接异常要进行释放重新建立连接三次握手

4.2断开连接

client给serverFINserverACK这就表明client要给你发的数据已经发完了我要给你断开连接server也给clientFINclientACKserver此时双方之间就完全断开了链接四次挥手完成

但server也可以选择不给clinetFIN你发完了但我要给你发的数据还没完server每给client发时虽然在client那边认为我已经跟server断开连接的但还是会给serverACK应答怎么理解

client给serverFIN说明client要给server发送的用户数据已经发完了关闭sockfd清理发送缓冲区断开‘连接’了但实际上TCP为了配合对方发送ACK连接没彻底断开server端还是能给clinet发送数据的

shutdown(sockfd,SHUT

在OS中我们会有很多连接有请求的连接正在通信的连接请求断开的连接怎么多连接OS怎么管理

先描述在组织建立内核结构体进行管理

一次握手就建立连接的话client可以给server发送大量SYNserver建立连接时需要成本的每个连接占一点资源有可能会让server崩溃

client可以不处理)那如果这样的话三次握手也是可能造成SYN洪水的啊

但三次握手相对而言比一次两次来说更好些最后一次ACK时client发的clientOS内部也要管理连接(需要成本)持续攻击client也会崩溃

5.1建立连接为什么要三次握手

client给serverSYNserverACK说明clinet给server发的消息

server能收到

server给clientSYNclientACK说明server给clinet发的消息

clinet能收到

这样既能说明双方网络连通也说明了client能发和收server能收和发

client给serverSYNserverACK说明server同意与clinet进行连接

server给clientSYNclinetACK说明clinet同意与server进行连接

而server给client的SYN和ACK实际在握手时采用的是捎带应答(一次搞定效果是一样的)

5.2重新理解四次挥手

与为什么三次握手的理由类似也是要知道双方的距离与意见问题至于为什么是四次而不是三次主要是为了处理我们上面的特殊情况client要断开连接而server不想断开的情形

5.3验证状态

将http写的代码中把请求处理好后不关闭sockfd就能看到现象

//TcpServer.hpp

std::functionstd::string(std::string);class

TcpServer

_listensockfd(std::make_sharedTcpSocket()),

_isrunning(false){_listensockfd-Tcp_ServerSocket(_port);

socket

_listensockfd-AcceptSocket(client);if

(newsock

_sockfd(sockfd),_self(self),_addr(addr){}};static

void

*args){pthread_detach(pthread_self());PthreadDate

*date

requeststr;date-_sockfd-Recv(requeststr);std::string

reponsestrdate-_self-_server(requeststr);

进行回调date-_sockfd-Send(reponsestr);//date-_sockfd-Close();

不关闭

如何我们的服务器卡顿查一下是不是存在大量的CLOSE_WAIT状态是的话把sockfd关闭

TIME_WAIT

如果我们想看到TIME_WAIT状态先让server退在让client退在server就能看到现象

平时在运行server时如果server退了想再次重启时我们会发现bind失败要换端口号才能解决原因就是进程连接退了但OS所维护的连接没退还在TIME_WAIT中端口号被占用

使用setsockopt设置创建的sockfd就能解决TIME_WAIT问题解决历史遗留问题

void

/proc/sys/net/ipv4/tcp_fin_timeout

RTO(超时重传时间)

我们都知道但一方把数据发送给对方时我们在某个时间间隔没有进行ACK时就要进行重传当对方没收到该报文有可能是网络差报文正处在某个路由器阻塞着这么说这个报文的生存时间明显要大于重传时间长时间下来在网络里可能存在着很多积攒下来的报文四次挥手后在clinet看来是断开连接的实际上在OS中并没有断开在等待着网络中历史报文收到并清除防止后面我们在进行连接时(用相同的端口号)进行一定干扰

有了这个TIME_WAIT时间在第四次挥手时如果ACK丢了对方会持续想我们发送FIN来提醒我们丢包了好让我们进行ACK应答

6流量控制

在发送报文时有时会遇到发送方发送过去的报文接收方的接收缓冲区满了会对收到的报文进行丢弃这合理吗

有人可能会说报文被丢弃了TCP保证可靠性不是有超时重传吗重传下不就好了

这虽然有道理但我把报文经过CPU资源流量等花费千里迢迢到达目的地接收方只是因为接收缓冲区满了就丢弃了它有没有什么错所以我们要根据接收方的接收能力

那我作为发送方怎么知道

发送报文时接收方不是要给我们ACK吗除了在报头里吧ACK标志位置1它还要更新16位窗口大小填写是自己的接收能力对方送到后就能动态调整发送数据的大小啦

接收方接收缓冲区满了我们就要把发的速度由快变慢但有没有可能接收方缓冲区很大发送方

发送还太慢呢

这时完全有可能的这时接收方上层已经嗷嗷待哺了发送方发送速度还这么慢这时完全不合理的

现在两台主机都知道对方的接收能力了可以根据剩余空间大小做调整但如果发送方首次给接收方发送报文应该发多大

但关键是要发多少100字节200字节那如果接收方接收缓冲区故意设置得很小呢

首次给对方发报文这个说法不怎么准确在那期间我们双方进行连接时要进行三次握手这不就是给对方发送报文吗发送报文除了把SYN置1/ACK置1自己的属性数据(如流量大小)也要填写后发送告知对方也就是说在三次握手期间双方就已经交换了双方的接收能力

既然双方都知道了接收能力也就能根据对方实际情况发送合理的数据了这时我们把它推导到极端接收方剩余空间为0发送方要怎么办接收方不为0了接收方又要怎么办

就会将窗口置为

但是需要定期发送一个窗口探测空报文看看接收方的情况当接收方窗口不为0时会主动给发送方发送窗口更新通知空报文发送方我能够接收数据了快来给我发送消息吧

在这里如果接收方窗口不更新发送方一直窗口探测的结果一直是0这该怎么办

那么这时发送方就会将要发送的报文中把PSH标记位置1让接收方尽快处理数据把接收缓冲区的数据尽快取走

1暂停

如果没有紧急指针那么我们想取消的这个需求等前面数据传输后才能取消这样就很费资源

根据数据进行处理动作

在写代码过程中要想进行发送接收紧急数据时就要用到recv,send参数中的falgsMSG_OOB

要想实现我们可以启用两个线程一个正常通信一个负责紧急数据处理但这个实用性不高(如果要更换需求,整个代码可能会受影响)一般推荐用ftp协议(两个端口分开处理后续改动不大

7滑动窗口

先不着急理解这些我们先来看看TCP的两种通信模式一种是发送一个报文确认应答后再发送报文我们说这种效率不高所以有了第二种方式在一个时间段内发送多个报文同时会收到多个应答在这里我们发送的多个报文的前提下是对方要来得及接收的所以在发送方这里我们要来规定出一个概念

左边是已发送已确认数据自己是暂时不用收到应答直接发送右边是未发送未确认数据

7.1两个问题

以目前来说好像是只能向右滑不能向左滑因为往右滑动时左边的数据是已发送已应答了没必要再次发重复数据

窗口大小(暂时)代表着接收方的接收能力当本次发送报文时接收方给我ACK的窗口大小变大滑动窗口不就变大了变小也类似如果接收方不处理接收缓冲区的数据ACK的窗口大小肯定会越来越小甚至最后变0也就是滑动窗口为零

char

要想指针所指的范围变大win_end变大的速度大于win_start也就是更新窗口大小变大

要想指针所指的范围变小甚至变成零win_start变大的速度大于win_end甚至win_start

win_end也就是接收方不处理接收缓冲区的数据窗口大小变小(最后变为零)

7.2丢包问题

比如1001~2000的报文丢失而后面的报文发送成功那么主机B

ACK应答时确认序号全是1001代表1001之前的数据主机B已经收到TCP识别主机A收到3个以上ACK应答就会认为最左侧丢失触发快重传机制进行补发

一点都不会如果双方通信接近末期了主机A收到了2个相同的ACK确认应答快重传没触发此时就由超时重传来接管也就是说快重传是在超时重传的基础上提高效率而超时重传是在为快重传没法触发时兜底的

这种我们就看最新的ACK应答来判断那个报文丢失从而进行补发最新丢了看次新的...

b快重传

中间报文丢失因为中间报文丢失而最左侧报文发送成功并收到了应答win_start向右移动此时中间报文变成最左侧报文

7.3关于滑动窗口

不会我们在逻辑上把发送缓冲区理解成数组但物理上它是环形队列不会出现越界情况

不用滑动窗口向右滑动也就把左边数据默认已经是没用数据随时可被新数据所覆盖~

8拥塞控制

以上的TCP策略我们只考虑发送方到接收方的问题不考虑网络问题那如果此时通信出现网络拥塞了如何识别出来是网络的问题

(上帝视角)当server给client发送1000个报文时有999个报文被对方收到只有一个出现丢包这时server会认为很正常重新对丢包报文进行补发但如果是999个报文出现丢包server就会认为出现严重的网络拥塞了停止发送报文

这时可能会有人说了不就是网络拥塞了吗重新补发999个报文不就好了为什么还要停止发送报文呢网络通信你不要以为只有你们(server和clinet)在通信还有其它server和client也在通信继续补发不是更加加剧网络拥塞吗

解决网络拥塞的意义在于多个使用同一个网络通信的主机有拥塞避免的共识

TCP引入慢启动机制,

网络好的情况用应答窗口网卡情况用拥塞窗口使得滑动窗口的大小最终一定是小于等于对方接收能力的

定义拥塞窗口大小为1;每次收到一个

由于网络状态是浮动的那么也就说明拥塞窗口大小也必然是浮动的那主机应该这样得知拥塞窗口的大小是多大

多轮尝试慢启动发送数据呈现指数级增长(2^n)前期慢后期快增幅大减小网络发送让网络恢复(前期慢)网络一旦恢复了我们的通信过程也要快速恢复起来(后期快)

不再按照指数方式增长,

线性增长探测到网络拥塞了更新出拥塞窗口大小线性增长更新的大小较准确了下次传输从1开始重新进行探测拥塞窗口大小新的ssthresh值是上次更新的拥塞窗口的一半

这是有可能的但在不同的系统中拥塞窗口大小一般是有上限的而网络状态一定在某个时刻会出现些许波动不可能一直是流畅的状态毕竟万事无绝对嘛

9延迟应答

如果延迟应答后上层还是未处理接收缓冲区的数据ACK的窗口大小不还是跟之前的一样(在这种情况下)延不延迟好像没必要吧

延迟应答是保证数据能在短时间内被上层处理好给对方ACK告诉对方我能接收更多的数据如果短时间内未被处理慢ACK与快ACK是不影响通信的而慢ACK有概率触发数据被上层处理提高传输效率

数量限制:

在建立连接时第三次握手client给server发ACK时就可以捎带应答(前两次不行)在给serverACK的同时携带数据因为给serverACK时client认为连接已经是建立好了的

11TCP异常问题

给client定期发消息检测连接是否存在的做法也可以在应用层中体现例如前面的socket编程中给client

echo_server

的socket的同时会在内核中创建一个发送缓冲区和一个接收缓冲区;

write

这个问题就如同北方城市蒸包子蒸好的包子之间如果没有距离你去拿一个包子时会无从下手可能拿上来是一个半包子也可能是半个包子...

对于UDP来说没有粘包问题

站在应用层的角度recvform读取字节一定是对方发送的字节数不可能出现少读多读的情况

对于TCP来说存在粘包问题

保证每次都按固定大小读取即可;requestreponse结构

还可以在包和包之间使用明确的分隔符例如用\r\n表示包的结束位置

扩展理解

在之前学习文件时我们往文件里写入各种数据结构intfloatchar类型...将文件里的数据给读上来时会发现很难进行解析我们会这样

因为打开文件时就是面向字节流的语言层学习文件时少了粘包问题与反序列化的相关知识所以会发现往文件里写好写读就不好读粘包问题要解决

在之前的序列与反序列化中我们用json进行序列化成字符串在encode(添加报头用分隔符隔开)后往网络里写

现在变成往文件里写要把文件读上来不就是当时写client的逻辑decode(读取有效载荷后删除报文)后进行反序列化得到我们想要的数据

而在未来我们要学习的数据库redis,mysqt,mongodb...)把数据存到文件里再把数据读上来本质上是序列化与反序列化自己实现的协议

TCP

正常server与client通信的代码把server的accept部分给注释掉(修改backlog)还能不能连接

//tcpserver.cc

1,Socket_Err,Bind_Err,Listen_Err

};#define

sizeof(local));local.sin_family

htons(_port);local.sin_addr.s_addr

htonl(INADDR_ANY);//

ntohs(peer.sin_port);std::string

clientip

inet_ntoa(peer.sin_addr);std::string

prefix

std::to_string(clientport);std::cout

get

continue;//}ProcessConnection(sockfd,

peer);}}~TcpServer(){}private:uint16_t

_port;int

stoi(argv[1]);std::unique_ptrTcpServer

tsvr

make_uniqueTcpServer(port);tsvr-Init();tsvr-Start();return

}//client.cc

serverAddr;serverAddr.sin_family

htons(serverport);

替换为服务器端口serverAddr.sin_addr.s_addr

替换为服务器IP地址int

std::endl;::close(clientSocket);return

1;}while

(message.empty())continue;send(clientSocket,

message.c_str(),

std::endl;}}::close(clientSocket);return

我们所用的公网IP是云服务器厂商虚拟出来的机器真实的IP是内网IP但内网IP不便于进行公网访问但使用公网IP时内网IP会路由到公网IP里远程使用时用不了内网IP所以在对方看来就用公网IP来标识连接对方身份

再启动多个client端时

listen的第二个参数的作用全连接队列中已经建立三次握手成功的连接个数

backlog

在服务器来不及对连接进行accept时底层的TCP会允许用户进行三次握手但建立连接的个数不能太多

2理解全连接队列

(内核中)在传输层TCP中建立accept_queue队列维护的来不及处理的连接当有客户端来进行连接三次握手时在队列后面进行链接结构体内包含着各种基本信息当应用层进行accept获取连接时实际上是获取建立连接的结构体连接的本质是内核中的一种数据结构

在上面我们模拟的是应用层accept给注释掉(accept非常忙来不及进行accept)此时accept_queue队列的长度最大backlog

为什么全连接队列不能为空也不能太长

a应用层要用全连接队列中去拿新到来的连接加入到全连接队列中这不就是生产者消费者模型吗

c队列太长会浪费资源空间使得用户体验不好新到来的用户连接等待时间长

3内核层里socket和连接

array[]申请一个空间(3号数组下标listen_socket)返回给上层服务(进程)先要为我们创建出一个file对象这个file对象在底层创建出socket再通过type创建出tcp_scok(udp_sock)对象(连接)然后我们就能通过file对象的private

data找到socket再通过socket里的sock(多态的方式)访问到tcp_scok(udp_sock)里的所有数据

进行accept时在struct

array[]申请一个空间(4号数组下标普通socket)返回给上层来进行IO系统先创建出file和socket对象通过指针连接起来三次握手通过socket里的sock找到tcp_sockudp_sock这样在上层就能通过普通socket进行通信啦

关于连接

flags4163UP,BROADCAST,RUNNING,MULTICAST

mtu

serverAddr;serverAddr.sin_family

htons(serverport);

替换为服务器端口serverAddr.sin_addr.s_addr

替换为服务器IP地址int

std::endl;::close(clientSocket);return

1;}while

(message.empty())continue;send(clientSocket,

message.c_str(),

std::endl;}}::close(clientSocket);return

//tcpserver.cc

1,Socket_Err,Bind_Err,Listen_Err

};#define

sizeof(local));local.sin_family

htons(_port);local.sin_addr.s_addr

htonl(INADDR_ANY);//

ntohs(peer.sin_port);std::string

clientip

inet_ntoa(peer.sin_addr);std::string

prefix

std::to_string(clientport);std::cout

get

0){continue;}ProcessConnection(sockfd,

peer);sleep(1);//才能看到四次挥手close(sockfd);}}~TcpServer(){}private:uint16_t

_port;int

stoi(argv[1]);std::unique_ptrTcpServer

tsvr

make_uniqueTcpServer(port);tsvr-Init();tsvr-Start();return

}现象