概念

思维导图 | HTTP 超文本协议,让 HTTP 不再难懂(二)​

思维导图 | HTTP 超文本协议,让 HTTP 不再难懂(二)​

 

相关阅读:

 

 

一张导图

 

思维导图 | HTTP 超文本协议,让 HTTP 不再难懂(二)​

 

导图内容解析

 

  • http请求

    • 请求行+请求头(多个key-value对象)+一个空行+实体内容

    • 请求行

      • 请求方法

        • 常见方法:get post head

思维导图 | HTTP 超文本协议,让 HTTP 不再难懂

思维导图 | HTTP 超文本协议,让 HTTP 不再难懂

 

相关阅读:

 

 

一张思维导图:

思维导图 | HTTP 超文本协议,让 HTTP 不再难懂

高清大图请点击阅读原文查看,或复制链接跳转:

  • http://upload-images.jianshu.io/upload_images/4120002-02a489103a926128.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240

协议

  • HyperText Transfer Protocol,超文本传输协议
  • 一个无状态的请求/响应协议
  • 是因特网上应用最为广泛的一种网络传输协议,所有的WWW文件都必须遵守这个标准
  • 基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)

工作原理

  • 默认端口号为80

软件工程师需要了解的网络知识:从铜线到HTTP

软件工程师需要了解的网络知识:从铜线到HTTP(一)—— 前言

 写作目标

本文面向中国互联网届众多的“应用软件工程师”,确切地说,面向 web 后端工程师(Java、PHP),web 前端工程师,移动开发工程师(iOS、Android)。本文将从铜线讲起,一路讲到 HTTP,为大家剖析出一个真实的“网络”。

写作由来

内容来源

前两天我给一个要跳槽的做 iOS 的哥们儿讲了几个小时的网络,给他的面试铺路,在讲之前,我就意识到了这次的内容如果能够整理一下将会是一套丰富的面向软件工程师的网络教程。…

OSI七层模型简介-原创

OSI七层模型简介

不能跨层传递, 只有物理层能实现物理通信,而其它层是逻辑通信 .

OSI七层网络模型

TCP/IP四层概念模型

硬件 协议 数据单元 说明
应用层(Application) 应用层 HTTP,FTP,telnet,DNS,MQTT,
SMTP,SSH等
DATA  apache,nginx等
表示层(Presentation)  MIME SSL TLS XDR  包括数据格式转换、加密和压缩,涉及编码格式,图片格式等ASCII EBCDIC MIDI MPEG
会话层(Session)  Sockets ,RPC  会话层控制计算机之间的对话(连接)。建立、管理和终止本地和远程应用程序之间的连接(一般由多线程维持多个会话连接)操作系统/应用读取
传输层(Transport) 传输层  可有四层硬件 TCP, UDP Segment (TCP) / Datagram (UDP)  端口(port)到端口(找到应用程序)

OSI七层模型与TCP/IP五层模型

        博主是搞是个FPGA的,一直没有真正的研究过以太网相关的技术,现在终于能静下心学习一下,希望自己能更深入的掌握这项最基本的通信接口技术。下面就开始搞了。

一、OSI参考模型

        今天我们先学习一下以太网最基本也是重要的知识——OSI参考模型。
 1、OSI的来源
        OSI(Open System Interconnect),即开放式系统互联。 一般都叫OSI参考模型,是ISO(国际标准化组织)组织在1985年研究的网络互连模型。
        ISO为了更好的使网络应用更为普及,推出了OSI参考模型。其含义就是推荐所有公司使用这个规范来控制网络。这样所有公司都有相同的规范,就能互联了。
  2、OSI七层模型的划分
       OSI定义了网络互连的七层框架(物理层、数据链路层、网络层、传输层、会话层、表示层、应用层),即ISO开放互连系统参考模型。如下图。
        每一层实现各自的功能和协议,并完成与相邻层的接口通信。OSI的服务定义详细说明了各层所提供的服务。某一层的服务就是该层及其下各层的一种能力,它通过接口提供给更高一层。各层所提供的服务与这些服务是怎么实现的无关。
    
 3、各层功能定义
        这里我们只对OSI各层进行功能上的大概阐述,不详细深究,因为每一层实际都是一个复杂的层。后面我也会根据个人方向展开部分层的深入学习。这里我们就大概了解一下。我们从最顶层——应用层 开始介绍。整个过程以公司A和公司B的一次商业报价单发送为例子进行讲解。
<1>    应用层
        OSI参考模型中最靠近用户的一层,是为计算机用户提供应用接口,也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有:HTTP,HTTPS,FTP,POP3、SMTP等。
        实际公司A的老板就是我们所述的用户,而他要发送的商业报价单,就是应用层提供的一种网络服务,当然,老板也可以选择其他服务,比如说,发一份商业合同,发一份询价单,等等。
<2>    表示层
        表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要,该层可提供一种标准表示形式,用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。
        由于公司A和公司B是不同国家的公司,他们之间的商定统一用英语作为交流的语言,所以此时表示层(公司的文秘),就是将应用层的传递信息转翻译成英语。同时为了防止别的公司看到,公司A的人也会对这份报价单做一些加密的处理。这就是表示的作用,将应用层的数据转换翻译等。
<3>    会话层
        会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。      
        会话层的同事拿到表示层的同事转换后资料,(会话层的同事类似公司的外联部),会话层的同事那里可能会掌握本公司与其他好多公司的联系方式,这里公司就是实际传递过程中的实体。他们要管理本公司与外界好多公司的联系会话。当接收到表示层的数据后,会话层将会建立并记录本次会话,他首先要找到公司B的地址信息,然后将整份资料放进信封,并写上地址和联系方式。准备将资料寄出。等到确定公司B接收到此份报价单后,此次会话就算结束了,外联部的同事就会终止此次会话。
<4>   传输层

TCP连接的关闭

TCP连接的关闭

多线程多进程关闭连接的区别

  首先来看看close和shutdown两个系统调用对应的内核函数:

TCP连接的关闭

 

TCP连接的关闭

  上图是调用close和shutdown关闭连接时的函数调用过程,sys_close和sys_shutdown这两个系统调用最终是由tcp_close和tcp_shutdown方法来实现的。

  由此我们可以来看一个问题:当socket被多进程或者多线程共享时,关闭连接时有何区别? 
  从图中可以看到sys_close封装调用过程中有一个fput函数,它有一个引用计数,记录这个socket被引用了多少次。当这个引用计数不为0时,是不会触发真正关闭tcp连接的tcp_close方法的。

  引用计数是怎么来的呢?创建进程和线程都是由clone系统调用实现的,只不过clone的参数不同,行为也不同。

  在clone系统调用中,会调用方法copy_files来拷贝文件描述符(包括socket)。创建线程时,传入的flag参数中包含标志位CLONE_FILES,此时,线程将会共享父进程中的文件描述符。

  而创建进程时没有这个标志位,这时,会把进程打开的所有文件描述符的引用计数加1。所以子进程会将父进程中已经建立的socket加上引用计数,当进程中close一个socket时,只会减少引用计数,仅当引用计数为0时才会触发tcp_close。

  单线程(进程)中使用close与多线程中是一致的,但这两者与多进程的行为并不一致,多进程中共享的同一个socket必须都调用了close才会真正的关闭连接。

  shutdown是没有引用计数什么事的,只要调用了就会去试图按需关闭连接。所以shutdown与多线程、多进程无关。

close发生了什么

  TCP连接是全双工的连接,及连接双方可以并行的发送或者接收消息。这样关闭连接时就存在3种情形:完全关闭连接; 关闭发送消息的功能;关闭接收消息的功能。其中,后者就叫做半关闭,由shutdown实现,前者用close实现。

  我们现在来看看close。

 

TCP连接的关闭

我们依次来看一下这三种情形:

1)关闭监听句柄

  用于listen的监听句柄是close关闭的,它本身并不对应着某个连接,但是附着在它之上的却可能有半成品连接,即1、2次握手完成,第3次未完成,就会在服务器上有许多半连接,close的工作主要是清理这些半连接。

  keepalive定时器是干嘛的?keepalive是TCP中一个可以检测死连接的机制,侧重在保持客户端和服务端的连接,防止僵死、异常退出的客户端占用服务器连接资源。

  比如A与B建立连接后,突然B宕机了,之后时间内B再也没有起来,如果B宕机后A和B一直没有数据通信的需求,A就永远不会发现B已经挂了,那么A的内核里还维护着一份关于A与B之间TCP连接的信息,浪费系统资源。

  所以TCP层面引入了keepalive机制,A会定期给B发送空的数据包,通俗讲就是心跳包。

  内核对于tcp keepalive的调整主要有以下三个参数:

TCP连接的关闭

  当tcp发现未收到对端数据时,开始以间隔tcp_keepalive_intvl(75)秒的频率发送心跳包。

  如果连续tcp_keepalive_probes(9)次以上未响应代表对端已经down了,close该连接。

  参照上图,close首先会移除keepalive定时器,移除此定时器后,若ESTABLISH状态的TCP连接在tcp_keepalive_time时间(如服务器上常配置为2小时)内没有通讯,服务器就会主动关闭连接。接下来,发送RST包去关闭每一个半连接,处理完所有半打开的连接close的任务就基本完成了。

2)关闭普通ESTABLISH状态的连接(未设置so_linger,默认)

  首先检查是否有接收到却未处理的消息。如果有,根据close的行为是要丢掉这些消息的。

  但丢弃消息后,意味着远端误以为发出的消息已经被本机处理了(因为ACK包确认过了),但实际上是收到未处理,此时不能使用正常的四次握手关闭连接,而是会向远端发送一个RST非正常复位关闭连接。所以这要求程序员在关闭连接前,确保接收并处理了连接上的消息。

  如果此时没有未处理的消息,那么发送FIN来关闭连接。这时,再看看是否有待发送消息,如果有,那么会在最后一个报文中加入FIN标志,同时关闭angle算法,一次性将所有包发出;如果没有未发送消息,则仅发送一个FIN报文,发送出去关闭连接。

3)使用了so_linger的连接

  so_linger是干嘛的?so_linger决定系统如何处理残留在套接字发送队列中的数据。我们可能有强可靠性的需求,也就是说,必须确保发出的消息、FIN都被对方收到。

  怎么做到呢?就是等待,close会阻塞住进程,直到对方确认收到了再返回,但是如果对方总是不响应怎么办呢?所以还需要l_linger这个超时时间,控制close阻塞进程的最长时间。

TCP连接的关闭

  上图是l_linger参数的设置及其对应的行为,默认情况下是第一种情况。

  当使用了so_linger后,前半段仍然没有变化。首先检查是否有未处理消息,有则发RST关连接。

  接下来检查是否有未发送消息,这种与第二种情况一致,设好FIN后关闭angle算法。接下来,会设置最大等待时间l_linger,然后进程开始睡眠,直到确认对方接收到消息,将控制权交还给用户进程。

  总结一下就是:调用close时,可能导致发送RST复位关闭连接,例如有未读消息、打开so_linger但l_linger却为0、关闭监听句柄时半打开的连接。更多时会导致发FIN来四次握手关闭连接,但打开so_linger可能导致close阻塞等待着对方的ACK表明收到了消息。

本文转自:小组15级成员–杜肖孟

原文地址:http://blog.csdn.net/tanswer_/article/details/78422879

TCP/IP指南

组织:中国互动出版网(http://www.china-pub.com/)
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:ouyang@china-pub.com
译者:(   )
译文发布时间:2001-12-28
版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留
本文档的翻译及版权信息。




Network Working Group                                      T. Socolofsky
Request for Comments:  1180                                      C. Kale
                                                  Spider Systems Limited
                                                            January 1991

  
  

TCP/IP指南
(RFC1180——A TCP/IP Tutorial)
  
本备忘录的状态
  
这本 RFC 是 TCP/IP 协议的指南, 重点介绍通过一个路由 
器从来源主机提交一个 IP 数据包到目的地主机的步骤。 
它不指定一个因特网标准。 
  
目录
  

paddlepaddle的个性化推荐教程

个性化推荐

本教程源代码目录在book/recommender_system, 初次使用请参考PaddlePaddle安装教程,更多内容请参考本教程的视频课堂

背景介绍

在网络技术不断发展和电子商务规模不断扩大的背景下,商品数量和种类快速增长,用户需要花费大量时间才能找到自己想买的商品,这就是信息超载问题。为了解决这个难题,推荐系统(Recommender System)应运而生。…

Page 1 of 612345...Last »