网络相关之网络基础

最近在看关于HTTP相关的东西,今天先记录一部分,因为关于这块的东西要讲起来,还是挺多的。关于今天这篇文章,这篇文章的脉络是网络的结构,然后再说数据信息在是怎样在网络中流动的。

网络的结构

首先网络是分层的,类似于一种降低耦合的思想,每一层之间相互独立,某一层出现问题只需要调整这一层就行,不用大动干戈,易于维护,灵活性好。


20180215075820426.png

应用层

应用层主要负责整块数据的发送和接收。
应用层对应着许多协议,比如HTTP,FTP等等,这里简单介绍一下HTTP;
HTTP 分请求报文和相应报文。

请求报文

HTTP请求报文是客户端向服务端发送请求的详细内容,里边包含请求方法,请求的URL,报文头部,以及报文体。


HTTP请求报文.jpg

响应报文

HTTP响应报文是服务端向客户端发送响应的详细内容,内部包含响应状态码及描述,响应头部以及响应实体。


HTTP响应报文.jpg

请求和响应的数据都会交给传输层去发送,这一层也是最接近用户的一层。

传输层

传输层对应着TCP,UDP。
传输层负责将数据拆分和整合。TCP还要多做回执和重发的操作,因为TCP是确保传输成功的协议,需要给发送方回执,告诉发送方:“嗯,我收到了。”;当发送失败的时候,TCP还需要进行重发操作。而UPD是不保证数据是否发送成功的,我只管发送数据和接收数据,成不成功俺才不管。
这边主要讲一下TCP的一些工作原理。参考TCP 详解

TCP连接(三次握手机制)

TCP的连接是通过三次握手机制连接上的。
1.客户端--(我需要连接你)-->服务端
2.服务端--(我知道你要连接我)-->客户端
3.客户端--(我知道你知道了)-->服务端

TCP三次握手.png

通过三次握手机制之后,客户端和服务端连接建立,可以进行数据传输。
三次握手机制是比较可靠的一种机制,如果使用两次握手的话,可能会造成一些问题,比如发送了一个连接请求之后,这个请求很调皮,本来它的任务失去服务端报信的,却跑出去玩了;客户端迟迟没有收到回信,于是又发出了一个连接请求,服务端和客户端建立了连接,进行了数据传输工作之后,服务器和客户端就关闭了连接。此时,之前的请求玩得尽兴了,跑到了服务器那边,服务器于是进行了回复,连接建立。因为两次握手的原因,此时客户端是没有想着建立连接的,问题就产生了。如果是三次握手机制的话,服务端给客户端回复之后,因为客户端并没有这个请求,所以也就不会响应,那么这个连接也不会建立。

TCP关闭连接(四次挥手)

当TCP连接要关闭连接的时候,需要经过四个步骤。
1.客户端--(我要断开连接)-->服务端
2.服务端--(我知道你要断开连接)-->客户端
--------服务端往客户端发最后的数据--------
3.服务端--(我同意断开连接)-->客户端
4.客户端--(我收到你同意断开连接的消息)-->服务端

TCP四次挥手.png

TCP断开连接需要四个步骤,比连接多一步。原因是什么呢?根本原因是为了保证可靠性稳定性,保证连接一定是断开了。因为客户端想要断开连接之前,两方是正在进行数据传输的,那么客户端想要断开连接的时候,服务器可能还有数据要向客户端发送,那么服务端就需要将这些数据发送完毕才允许断开连接。
上图中客户端在发出最后一次消息的时候经历了TIME-WAIT状态才进入关闭状态,那么为什么要经历TIME-WAIT状态呢?

第一,保证客户端发送的最后一个ACK报文能够到达服务器。因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。
第二,防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

TCP数据传输

当经过了三次握手建立了连接之后,就可以进行数据传输了。
TCP是将应用层给过来的数据分块标记序号进行传输。发送方发送一块数据过去,接收方收到之后要进行回应,如果规定时间发送方没收到回应,发送方会进行重发。
其中TCP传输阶段使用了很多的机制来保证数据传输的可靠稳定并且高效率。关于这些机制这里就不一一列举了,看下我给出的参考。
数据传输完成,需要断开连接的时候,就需要进行四次挥手。

网络层

网络层里边工作着的是IP。
网络层是为传输层提供服务,传送的是数据包。

主要作用

主要作用:一,是解决如何是数据包通过各节点传送的问题,即通过路径选择算法(路由)将数据包传送到目的地。二,为避免通信子网中出现过多的数据包而造成网络阻塞,需要对流入的数据包数量进行控制(拥塞控制)。三,数据包要跨越多个通信子网才能到达目的地时,还要解决网际互连的问题。

地址

由网络地址和主机地址自称,网络地址是唯一的。

主要协议

IP: 承载要发送的消息
ARP :用来找到目标主机的Ethernet网卡Mac地址。

链路层

物理设备等。
链路层负责数据在物理世界的传输。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,012评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,628评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,653评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,485评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,574评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,590评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,596评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,340评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,794评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,102评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,276评论 1 344
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,940评论 5 339
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,583评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,201评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,441评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,173评论 2 366
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,136评论 2 352

推荐阅读更多精彩内容