这里就不贴源码了，源码分析的话，网上一大堆，我这里只是简要的描述下epoll的实现和一些关键的代码片段。 相关的文件在 fs/eventpoll.c中,我看的是2.6.38的内核代码. 1 epoll在创建的时候会调用anon_inode_getfd新建一个file instance，也就是epoll可以看成一个文件。因此我们可以看到epoll_create会返回一个fd.
本文以完整的源码的方式介绍如何在Linux 2.6.25中实现select系统调用。 TAG: select模型 Linux 2.6.25中的select系统调用 主要有4个函数: sys_select：处理时间参数，调用core_sys_select。 core_sys_select：处理三个fd_set参数，调用do_select。 do_se
/** * 通过拼接的方式构造请求内容，实现参数传输以及文件传输 * @param actionUrl * @param params * @param files * @return * @throws IOException */ public static String post(String actionUrl, Map<String, String> para
在最初的 http 协议中，没有上传文件方面的功能。RFC1867（"Form-based File Upload in HTML".） 为 http 协议添加了这个功能。客户端的浏览器，如 Microsoft IE, Mozila, Opera
[转] RFC1867协议介绍
19 附录 19.1 互联网媒体类型message/http和application/http 这篇文档除了定义 HTTP/1.1协议外，还用作互联网媒介类型"message/http"和"application/http"的规范。此类型用于封装一个HTTP 请求消息或响应消息，这假设此类型遵循MIME对 所有“消息”类型关于
15．安全考虑 （Security Consideration） 这一部分是用来提醒程序开发人员，信息提供者，和用户关于HTTP/1.1安全方面的限制。讨论并不包含对披露问题的明确的解决办法，然而，确对减少安全风险提供了一些建议。 15.1 个人信息 （Personal Information） HTTP的客户端经常要对大量的个人信息保密（例如用户的名字，域，邮 件地址，口令，密匙等。），并
14 头域定义 本节定义了所有HTTP/1.1种标准头域的语法和语义。对于实体头域，发送者和接收者指的是客户端和服务器，取决于谁发送和谁接收此实体。 14.1 Accept Accept请求头域被用于指定服务器返回给客户端可接受的响应媒体类型。Accept头域能被用于指明请求是期望服务器返回某些期望的媒体类型的响应，例如请求一个内嵌的图像。 Accept
13 HTTP中的缓存 HTTP典型应用于能通过采用缓存技术而提高性能的分布式信息系统。HTTP/1.1协议包括的许多使缓存尽可能的工作的元素。因为这些元素与协议的其他方面有着千丝万缕的联系，而且他们相互作用、影响，因此有必要单独的来介绍基本的缓存设计。 如果缓存不能改善性能，他将一无用处。HTTP/1.1中缓存的目的是为了在很多情况下减少发送请求，同时在许多情况下可以不需要发送完整响应。前
11.入口验证（Access Authentication） HTTP提供一些可选的响应授权激发机制，这些机制能被用于服务器激发客户 端请求并且使客户端授权。常用访问授权框架，还有“basic”和“digest”授权规范，都在“HTTP Authentication：basic and Digest Access Authentic
10.状态码定义 每一个状态码在下面定义，包括此状态码依赖于方法的描述和响应里需要的任何元信息的描述。 10.1 通知的 1xx 这类状态代码指明了一个备用的响应，包含一个Status-Line和可选的头域，并且一一个空行结束（译注：空 行就是CRLF）。没有必须的头域对这类状态码。因为HTTP/1.0没有定义任何1xx状态码，所以服务器不能发送一个1xx响应给一个HTTP /1
９ 方法定义（Method Definitions） HTTP/1.1常用方法的定义如下。虽然方法可以被展开，但新加的方法不能认为能分享与扩展的客户端和服务器同样的语义。 Hst请求头域（见13.23节）必须能在所有的HTTP/1.1请求里出现。 9.1 安全和等幂（Idempotent）方法 9.1.1安全方法（Safe Methods） 实现者应当知道软件是代表用户在互联网上进行交
8 连接 8.1 持续连接（Persistent Connection）。 8.1.1目的 在持续连接之前，为获取 每一个URL指定的资源都必须建立了独立的TCP 连接， 这就加重了HTTP服务器的负担，易引起互联网的阻塞。嵌入的图片与其它相关数据通常使用户在短时间内对同一服务器提交多个请求。目前已有针对这些性能问 题的分析以及原型实现的结果[26][30]。 对其他方法也有了初步探
7 实体（Entity） 如果不被请求的方法或响应的状态码所限制，请求和响应消息都可以传输实体。 实体包括实体头域（entity-header）与实体主体（entity-body），而有些响应只包括实体头域（entity-header）。 在本节中的发送者和接收者是否是客户端或服务器，这依赖于谁发送或谁接收此实体。 7.1 实体报文域（Entity Header Fields） 实体（en
６ 响应 （Response） 接收和翻译一个请求消息后，服务器发出一个HTTP响应消息。 response ＝Status-Line &nbs
5 请求（Request） 一个请求消息是从客户端到服务器端的，在消息首行里包含方法，资源指示符，协议版本。 Request = Request-Line ; Section 5.1 *（（ general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ） CRLF） ; Section 7.1
4 HTTP消息 4.1 消息类型（Message Types） HTTP消息由从客户到服务器的请求和从服务器到客户的响应组成. HTTP-message = Request|Response ;HTTP/1.1 请求（第5节）和
3 协议参数 3.1 HTTP版本 HTTP使用一个“<major>.<minor>”数字模式来指明协 议的版本号。协议的版本号是为了让发送端指明消息的格式和它的能力，这是为了进一步的HTTP通信，而不仅仅是获得通信的特征。协议版本是不需要修改的， 当消息组件的增加不会影响通信行为或着只增加了扩展的域值。<minor>数字是递增的，当
2 符号习惯和一般语法 2.1 扩充的BNF（扩充的 巴科斯-诺尔范式） 本文档规定的所有机制都用两种方法描述：散文体（prose）和类似于RFC 822的扩充Backus-Naur Form（BNF）。要理解本规范，使用者需熟悉符号表示法。扩充BNF结构如下： 名字（name）=定义（definition） 名字（name）就是代表规则的名字（译注：如：CRLF，DIGIT等等都是规则
说明 本文档规定了互联网社区的标准组协议，并需要讨论和建议以便更加完善。请参考 “互联网官方协议标准”（STD 1）来了解本协议的标准化状态。本协议不限流传发布。 版权声明 Copyright （C） The Internet Society （1999）. All Rights Reser
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
