精华内容
下载资源
问答
  • Java携带HTTP头信息下载网络图片

    千次阅读 2019-03-12 10:48:27
    Java携带HTTP头信息下载网络图片 网络图片下载校验一般分两种情况: 1、校验Reffer头信息,即只有指定的网站的才能访问图片 2、校验Cookie头信息,即只有登录状态才能访问图片 如下图直接通过url访问返回:{"code...

    Java携带HTTP头信息下载网络图片

    网络图片下载校验一般分两种情况:
    1、校验Reffer头信息,即只有指定的网站的才能访问图片
    2、校验Cookie头信息,即只有登录状态才能访问图片
    如下图直接通过url访问返回:{"code":"40310014","msg":"invalid Referer header"}

    原http访问图片携带了Reffer

    工具代码 

    /**
    	 * 携带头信息下载网络图片
    	 * @param url 图片url
    	 * @param formatName 文件格式名称
    	 * @param localFile 下载到本地文件
    	 * @param headers http协议交互中header信息,如Cookie
    	 * @return 下载是否成功
    	 */
    	public static boolean downloadImageWithHeaders(String imageUrl, String formatName, File localFile, Map<String, String> headers) {
    		boolean isSuccess = false;
    		InputStream stream = null;
    		try {
    			URL url = new URL(imageUrl);
    			URLConnection conn = url.openConnection();
    			if (headers != null && !headers.isEmpty()) {
    				//设置头信息
    				for (Map.Entry<String, String> entry : headers.entrySet()) {
    					conn.setRequestProperty(entry.getKey(), entry.getValue());
    				}
    			}
    			conn.setDoInput(true);
    			stream = conn.getInputStream();
    			BufferedImage bufferedImg = ImageIO.read(stream);
    			if (bufferedImg != null) {
    				isSuccess = ImageIO.write(bufferedImg, formatName, localFile);
    			} else {
    				throw new RuntimeException("图片[" + imageUrl + "]下载失败");
    			}
    		} catch (MalformedURLException e) {
    			e.printStackTrace();
    		} catch (IOException e) {
    			e.printStackTrace();
    		} finally {
    			if (stream != null) {
    				try {
    					stream.close();
    				} catch (IOException e) {
    					e.printStackTrace();
    				}
    			}
    		}
    		return isSuccess;
    	}

    测试代码

    /**
    	 * 测试携带请求头
    	 */
    	@Test
    	public void testDownloadImageWithHeaders() {
    		String baiduLogoUrl = "http://pic.58pic.com/58pic/15/68/59/71X58PICNjx_1024.jpg";
    		File localFile = new File(IMAGE_PATH + "scenery.jpg");
    		Map<String, String> headers = new HashMap<String, String>();
    //		headers.put("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8");
    //		headers.put("Accept-Encoding", "gzip, deflate");
    //		headers.put("Accept-Language", "zh-CN,zh;q=0.9,en;q=0.8");
    //		headers.put("Cache-Control", "max-age=0");
    //		headers.put("Connection", "keep-alive");
    //		headers.put("Cookie", "referer=%22https%3A%5C%2F%5C%2Fwww.58pic.com%5C%2Ftupian%5C%2FBMP.html%22; qt_visitor_id=%228d800369135f0ea407efc30c35b855c0%22; qt_uid=0; qt_type=0; user-browser=%22baidu%22; history_search=%22%7B%5C%22BMP_%5C%22%3A%5C%22%5C%5C%5C%2Ftupian%5C%5C%5C%2FBMP.html%5C%22%7D%22; awake=0; qiantudata2018jssdkcross=%7B%22distinct_id%22%3A%2216956b4d4b859f-0f2dc330b57f7c-3a3a5c0e-2073600-16956b4d4b92bd%22%2C%22props%22%3A%7B%22latest_traffic_source_type%22%3A%22%E8%87%AA%E7%84%B6%E6%90%9C%E7%B4%A2%E6%B5%81%E9%87%8F%22%2C%22latest_referrer%22%3A%22https%3A%2F%2Fwww.baidu.com%2Flink%22%2C%22latest_referrer_host%22%3A%22www.baidu.com%22%2C%22latest_search_keyword%22%3A%22%E6%9C%AA%E5%8F%96%E5%88%B0%E5%80%BC%22%7D%7D; qt_utime=1551937913; FIRSTVISITED=1551937885.528; showAd:8d800369135f0ea407efc30c35b855c0=%22w6SIEgLKiJOIC5HVD3fKoJHKodaWmZy8mtm4zJbLytqWn5vMyZmWyZm4yJG4nwmWiIWIywr5zxj3AxnLCL2Pzci9iJeIlcj3DxjUiJOImsiSiNnOB6DFDgLTzxmIoJmSiMXHC6rFC5HVD423Aw4LiJOXntuXotm6ote3Fv3%3D%22");
    //		headers.put("Host", "pic.58pic.com");
    //		headers.put("If-Modified-Since", "Tue, 22 Jul 2014 15:40:16 GMT");
    //		headers.put("If-None-Match", "ae01753237194fa9a5badf2d90fd20d6");
    		headers.put("Referer", "http://image.baidu.com/search/detail?ct=503316480&z=0&ipn=d&word=%E5%9B%BE%E7%89%87&step_word=&hs=0&pn=0&spn=0&di=107250&pi=0&rn=1&tn=baiduimagedetail&is=0%2C0&istype=0&ie=utf-8&oe=utf-8&in=&cl=2&lm=-1&st=undefined&cs=1986179278%2C1118313821&os=1011800134%2C3605107432&simid=3440756675%2C361207036&adpicid=0&lpn=0&ln=1765&fr=&fmq=1552355383195_R&fm=&ic=undefined&s=undefined&hd=undefined&latest=undefined&copyright=undefined&se=&sme=&tab=0&width=undefined&height=undefined&face=undefined&ist=&jit=&cg=&bdtype=0&oriquery=&objurl=http%3A%2F%2Fpic.58pic.com%2F58pic%2F15%2F68%2F59%2F71X58PICNjx_1024.jpg&fromurl=ippr_z2C%24qAzdH3FAzdH3Fooo_z%26e3Bcbrtv_z%26e3Bv54AzdH3Ffitstwg2p7AzdH3F8cmbcl08_z%26e3Bip4s&gsm=0&rpstart=0&rpnum=0&islist=&querylist=&force=undefined");
    //		headers.put("Upgrade-Insecure-Requests", "1");
    //		headers.put("User-Agent", "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36");
    		Assert.assertTrue(ImageUtil.downloadImageWithHeaders(baiduLogoUrl, ImageUtil.JPG, localFile, headers));
    	}

    完整源码:https://github.com/ConstXiong/xtools

     


    【Java面试题与答案】整理推荐

     

    展开全文
  • IPv6数据报头部格式

    万次阅读 2017-05-11 20:37:34
    IPv6数据报头部格式

    文章摘自书籍《深入理解计算机网络 王达 机械工业出版社》
    IPv4数据报头格式请点击此处

    IPv6数据报头部格式

    RFC2460定义了IPv6数据报格式。总体结构上,IPv6数据报格式与IPv4数据报格式是一样的,也是由IP报头和数据(在IPv6中称为有效载荷)这两个部分组成的,但在IPv6数据报数据部分还可以包括0个或者多个IPv6扩展报头(Extension header), 如下图所示。IP报头部分固定为40字节长度,而有效载荷部分最长不得超过65535字节。


    这里写图片描述

    IPv6和IPv4之间的最大差别在于:IP地址的长度从32位到128位。
    通过裁剪IPv4报头中的某些字段,或把一些字段移入到扩展报头中,IPv6基本报头的总长度大大减小了。IPv6使用固定长度的基本报头,从而简化了转发设备对IPv6报文的处理,提高了转发效率。尽管IPv6地址长度是IPv4地址长度的4倍,但IPv6基本报头的长度只有40字节,为固定的IPv4报文头长度(不包括选项字段)的2倍。IPv5报头格式如下图所示。


    IPv6数据报头格式
    图片来源:https://www.oschina.net/news/29748/from-ipv4-to-ipv6

    各字段作用

    版本(Version)

    版本字段用来表示IP数据报使用的是IPv6协议封装,占4位,对应值为6(0110)。

    通信分类(Traffic Class)

    通信分类字段用来标识对应IPv6的通信流类别,或者说是优先级别,占8位,类似于IPv4中的ToS(服务类型)字段。

    流标签(Flow Label)

    流标签字段时IPv6数据报中新增的一个字段,占20位,可用来标记报文的数据流类型,以便在网络层区分不同的报文。流标签字段有源节点分配,通过流标签、源地址、目的地址三元组方式就可以唯一标识一条通信流,而不用像IPv4那样需要使用五元组方式(源地址、目的地址、源端口、目的端口和传输层协议号)。这样发动的最大好处有两点:一是流标签可以和任意的关联,需要标识不同类型的流(可以是非五元组)时,无需对流标签做改动;二是流标签在IPv6基本头中,使用IPSec时此域对转发路由器可见,因此转发路由器可以在使用IPv6报文IPSec的情况下仍然可以通过三元组(流标签、源地址、目的地址)针对特定的流进行QoS(质量服务)处理。

    有效载荷长度(PayLoad Length)

    有效载荷长度字段是以字节为单位的标识IPv6数据报中有效载荷部分(包括所有扩展报头部分)的总长度,也就是除了IPv6的基本报头以外的其他部分的总长度,占20位。

    下一个头部(Next Header)

    下一个头部字段用来标识当前报头(或者扩展报头)的下一个头部类型,占8位。每种扩展报头都有其对应的值。下一个头部字段内定义的扩展报头类型与IPv4中的协议字段值类似,但在IPv6数据报中,紧接着IPv6报头的可能不是上层协议头部(当没有扩展报头或者为最后一个扩展报头时才是上层协议头),而是IPv6扩展报头。这一机制下处理扩展报头更搞笑,因为标识了数据报中对应的上层协议或者扩展报头类型,转发路由器只需处理必须处理的扩展报头,提高了转发效率。

    跳数限制(Hop Limit)

    跳数限制于IPv4报文中的TTL字段类似,指定了报文可以有效转发的次数,占8位。报文每经过一个路由器结点,跳数值就减1,当此字段值减到0时,则直接丢弃该报文。

    源地址(Source IP Address)

    源IP地址字段标识了发送该IPv6报文源节点的IPv6地址,占128位。

    目的IP地址(Destination IP Address)

    目的IP地址字段标识了IPv6报文的接受节点的IPv6地址,占128位。

    IPv6扩展报头

    在各字段介绍中我们讲到了,IPv6报文中可以携带可选的IPv6扩展报头。IPv6扩展报头是跟在IPv6基本报头后面的可选报头。由于在IPv4的报头中包含了几乎所有的可选项,因此每个中间路由器都必须检查这些选项是否存在。在IPv6中,这些相关选项被统一移到了扩展报头中,这样中间路由器不必处理每一个可能出现的选项(仅有“逐跳选项”报头是必须要处理的),提高了处理器处理数据报文的速度,也提高了其转发的性能。
    IPv6扩展报头附加在IPv6报头目的IP地址字段后面,可以有0个,或者多个扩展报头。主要的IPv6扩展报头有一下几类:

    逐跳选项头(Hop-by-hop Options Header)

    本扩展报头类型值为0(在IPv6报头下一个头部字段中定义,下同)。此扩展报头须被转发路径所有节点处理。目前在路由告警(RSVP和MLDv1)与Jumbo帧处理中使用了逐跳选项头,因为路由告警需要通知到转发路径中所有结点,而Jumbo帧是长度超过65535字节的报文,传输这种报文需要转发路径中所有结点都能正常处理。

    目的选项头(Destination Options Header)

    本扩展报头类型值为60。只可能出现在两个位置:
    1. 路由头前,这是此选项头被目的节点和路由头中指定的结点处理;
    2. 上层头前(任何的ESP头后),此时只能被目的结点处理。
    移动IPv6中使用了目的选项头,称为家乡地址选项。家乡地址选项由目的选项头携带,用以移动结点离开“家乡”后通知接受节点此移动结点对应的家乡地址。接受节点收到带有家乡地址选项的报文后,会把家乡地址选项中的源地址(移动节点的家乡地址)和报文中源地址(移动节点的转交地址)交换,这样上层协议始终认为是在和移动节点的家乡地址通信,实现了移动漫游功能。

    路由头(Routing Header)

    本扩展报头类型值为43,用于源路由选项和移动IPv6。

    分段头

    本扩展报头类型值为44,用于标识数据报的分段,在IPv4中就有对应的字段。当源节点发送的报文超过传输链路MTU(源节点和目的节点之间传输路径的MTU)时,需要对报文进行分段时使用。

    认证头

    本扩展报头类型值为51,用于IPSec,提供报文验证,完整性检查。

    封装安全有效载荷头

    本扩展头类型值为50,用于IPSec,提供报文验证、完整性检查差和加密。

    上层头

    这是用来标识数据报中上层协议类型,如TCP、UDP、ICMP等。

    注意:目的选项头最多出现两次,一次在路由头前,一次在上层协议头前,其他选项头最多只能出现一次。IPv6节点必须能够处理选项头(逐跳选项头除外,它固定只能紧随基本报头之后)在任意位置出现,以保证互通性。

    总结

    对比IPv4数据报头部格式可以看出,IPv6去除了IPv4报头中的头部长度、标识、标志、段偏移、校验和、选项、填充这么多字段,却只增加了流标签这一个字段,因此IPv6报头处理和IPv4报头处理相比大大简化,提高了处理效率。另外,IPv6为了更好地支持各种选项处理,提出了扩展头的概念,新增选项时不必修改现有的结构就能做到,理论上可以无限扩展,体现了优异的灵活性。

    展开全文
  • IPV4数据报头部格式

    万次阅读 多人点赞 2017-05-11 15:56:00
    IPV4 数据报头部格式 1. 图解 2. 前言 3. 格式

    IPV4 数据报头部格式

    摘自:《深入理解计算机网络》 王达著 机械工业出版社

    图解


    IPV4数据报头部格式
    图片来自:http://blog.163.com/qhj4433210@126/blog/static/165975282201592251248584/


    IPv4数据报头头部格式表
    图片来自:http://blog.163.com/qhj4433210@126/blog/static/165975282201592251248584/

    前言

    发送端的网络层在收到它的上一层——传输层发来的数据段时,需要通过网络层协议将其封装成数据报,也就是加上网络层IP协议(在此仅以IP协议为例进行介绍)头部。IP协议头部主要是源和目的网络的IP地址,以便可以数据分段传输到目的网络中。然后数据包向下传输,到了数据链路层后又要封装成数据帧。
    与在数据帧格式中包括帧头和数据部分类似,一个IP数据报也包括报头和数据这两个部分,如上图所示。其中数据部分就是来自传输层的完整数据段,而报头部分是为了正确传输数据报而增加的网络层IPV4/IPV6协议信息。

    格式

    版本(Version)

    版本字段指定了IP数据报中使用的IP协议版本,占四位。如过协议是IPV4,则值为0100。

    头部长度(Header Length)

    头部长度字段指示IP数据报头部的总长度,IP数据报头部的总长度以4字节为单位,该字段占4位。当报头中无选项字段时,报头的总长度为5,也就是 5×4=20 字节(此时,报头长度的值为0101)。这就是说IP数据报头部固定部分长度为20字节。当IP头部长度为1111时,头部的固定长度为 15×4=60 字节。但报头长度必须是32位(四字节)的整数倍,如果不是,需要在选项字段的填充(PAD)字段中补0凑齐。

    区分服务(Differentialted Services)

    最开始IP数据报的这个字段为优先级和服务类型字段,又称为服务类型(ToS)字段,用于表示数据报的优先级和服务类型,占八位。它包括一个3位长度的优先级、4位长度的标志位。标志位分别是D(Delay延迟)、T(Throughput吞吐量)、R(Reliability可靠性)和C(Cost开销),分别表示延迟、吞吐量、可靠性和开销值,用来获得更好的服务。最高1位未用。
    1998年IETF在RFC2474中把IP数据报中ToS字段改名为服务字段,同样为8位,前6位构成DSCP(Different Services Code Point,区分服务码点),是IP优先级和服务类型字段的组合,定义了0~63共64个优先级。最后两位未使用。无论是哪种版本,该字段只有在使用区分服务时才起作用,如果没有区分服务,则该字段值为0。

    总长度(Total Length)

    总长度字段标识整个IP数据报的总长度,包括报头和数据部分,整个IP数据报的总长度以字节为单位,该字段占16位。由此可得出,IPv4数据报的最大长度为 2161 字节即65535字节(64KB)。
    说明:在网络层下面的每一种数据链路层都有自己的格式,其中包括表示数据字段的最大长度,这称为最大传送单元(Maximum Transfer Unit,MTU)。当一个数据报封装成链路层的帧时,此数据报的总长度(包括报头和数据部分)一定不能超过下面的数据链路层的MTU值

    标识(Identification)

    标识字段用于表示IP数据报的标识符,占16位,每个IP数据报有一个唯一的标识符。IP软件在存储器中维持一个计数器,每产生一个数据报,计数器就加1,并将此值赋给整个标识字段。但整个标识并不是序号,因为IP是无连接服务,数据报不存在按序接受的问题。当数据报由于长度超过下面数据链路层的MTU(最大传输单元)值而必须分段的时候,这个标识符的值就被复制到所有的数据报分段的标识字段中。相同的标识字段的值分段后的各数据报分段最后能正确地组装成原来的数据报。

    标志(Flags)

    标志字段用以指出该IP数据报后面是否还有分段,也就是这个字段时分段标志,占3位。目前只有前两位有意义:最低以为记为MF(More Fragment),如果MF=1,则表示后面还有分段,如果MF=0表示这已是某个数据报的最后一个分段;中间一位记为DF(Don’t Fragment),当DF=1时表示不允许分段,DF=0表示允许分段;最高1位没有使用。

    段偏移(Fragment Offset)

    段偏移字段用以指出该分段在数据报中的相对位置,也就是说,相对于用户数据字段的起点,该分段从何处开始,占13位。若有分段,段偏移以8字节为偏移单位,即每个分段的长度一定是8字节(64位)的整数倍。第一个分段偏移值就是0 0000 0000 0000,如果第一个分段一共是64字节,则0 0000 0000 1001,相当于10进制数的9,因为从第9个“8字节”数据块开始的。如果没有分段,则该字段值为0。

    生存时间(Time To Live)

    生存时间字段用来标识IP数据报在网络中传输的有效期,以秒来计数,占8位。最初的设计是以秒为单位,没经过一个路由器时,就在TTL(Time To Live)中减去数据报在路由器消耗掉的一段时间。若数据报在路由器消耗的时间小于1s,就把TTL值减1。TTL的建议值是32s,最长是 281=255 s。现在通常认为这个TTL是指数据报允许经过的路由器数,每经过一个路由器,则TTL减1,当TTL值为0时,就丢弃这个数据报。设定生存时间是为了防止数据报在网络中无限制地循环转发。

    协议(Protocol)

    协议字段用来标识此IP数据报在传输层所采用的协议类型(如TCP、UDP或ICMP等等),以便使目的主机的IP层直到应将数据部分上交给哪个处理过程,占8位。如TCP的协议号是6,等于二进制的0000 1010,UDP的协议号是17,等于二进制的0001 0001。

    校验和(Checksum)

    校验和字段用来检验IP数据报的报头部分(不包过“数据”部分)在传输到接收端后是否发生了变化,占16位。这是因为数据报每经过一个路由器,路由器都要重新计算一下报头检验和(因为一些字段,如生存时间、标识、段偏移等都可能发生变化),不检验数据部分可减少计算的工作量。

    检验和的计算方法

    利用校检和字段检验报头部分数据正确性的基本原理是:现在发送端校检和字段中填上一个特定的值,然后再接收端把包括校检和字段在内的报头部分进行二进制反码求和,再取反,如果结果为0,则表示报头部分在传输过程中没有发生变化,否则表示在传输过程中出现了差错。从以上可以看出,这里最关键的是在发送端计算出这个校检和的值。步骤如下:
    1. 把IP数据报报头中的校检和字段置0。
    2. 把头部看成由16位(2字节)位单位得数字组成,对每16位的二进制反码进行求和。如报头长度不是16位的整数倍数,则用0填充到16位的整数倍数。若此时校验和字段值为0,可以不计,因为0的反码仍为0。
    3. 以上得到的结果就是我们要求的校验和字段值,系统自动将其填入IP数据报报头的检验和字段中。
    4. 在接收端中,同样按照以16位为单位,对IP数据报报头部分进行二进制反码求和,再取反,如果结果为0,表示报头部分在传输过程中没有发生变化,否则表示发生了差错。但要注意,此时因位校验和字段已不再是0了,而是等于除了检验和字段外的其他字段的反码之和。现在在对校验码和字段值取反求和,再与其他字段的反码之和(相当于原来“校验和”字段的值)相加,结果肯定是全为1,因为这两个值互为反码;再取反后,结果肯定为0。这就是校验和的基本原理。

    例子

    假设有3个数(为了简便,在此均用4位表示):2(0010)、3(0011)、C(代表校验和字段值),计算C,即求2和3的反码之和,得到9(1001)。现在假设把这3个数(2,3,C)传送到接收端。在接收端也要对这3个数进行反码求和。因为2和3这两个的反码之和我们在计算C时已经计算过了,就是9(1001),现在只需要对C(校验和字段值)进行求反,得到6(0110)。把1001和0110相加,得到15(1111)。再取反,得到0(0000)。这就是这3个数在传输过程中没有出现差错的情况下得到的,这就是校验和的校验原理。

    源地址/目的地址(Source Address/Destination Address)

    源地址/目的地址这两个字段分别表示该IP数据报发送者和接受者的IP地址,各占32位。在这个数据报传送过程中,无论经过什么路由,无论如何分段,此两字段一直保持不变。

    选项(Option)

    选项字段支持各种选项,提供扩展余地。根据选项的不同,该字段时可变长,从1字节到40字节。用来支持拍错、测量以及安全等措施。作为选项,用户可以使用,也可以不使用它们。但作为IP协议的组成部分,所有实现IP协议的设备都必须能处理IP选项。在使用选项的过程中,如果造成了IP数据报的报头不是32位的整数倍,这时需要后面的填充字段凑齐。如果恰好是整数倍,则不需要填充字段。

    展开全文
  • Android网络数据传输之网络协议

    千次阅读 2015-10-30 11:46:50
    Android网络数据传输之网络协议说起网络数据之间的交互,我们就必须明白下网络的分层,知道网络从后台到客户端看到的有哪些步骤。网络的七层分层在实际手机端开发中,我们主要是通过接口向后台请求数据,然后数据...

    Android网络数据传输之网络协议

    说起网络数据之间的交互,我们就必须明白下网络的分层,知道网络从后台到客户端看到的有哪些步骤。

    网络的七层分层

    net

    在实际手机端开发中,我们主要是通过接口向后台请求数据,然后数据经过处理展示到手机客户端上。所以我们基本涉猎的就是传输层(TCP协议)和网络层(IP协议)。这就是我们俗称的TCP/IP协议。

    Android的网络编程分为2种:基于http协议和基于socket。

    在实际的开发中,我们多数情况是在http协议下进行网络数据的交互。网络数据交互有两种,一种是基于HttpURLConnection连接url进行交互,一种是基于HttpClient进行交互。

    基于HttpURLConnection

    (1)、HttpURLConnection的”GET”方式:

        //建立一个URL对象
        URL url = new URL("http://blog.csdn.net/mr_dsw");
        //获取HttpURLConnection对象
        HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
        httpURLConnection.setConnectTimeout(2000);
        //设置请求方式
        httpURLConnection.setRequestMethod("GET");
        //设置读取数据的事件
        httpURLConnection.setReadTimeout(2000);
        //设置是否使用缓存
        httpURLConnection.setUseCaches(false);
        //用于设置我们的请求头
        httpURLConnection.setRequestProperty("field","newValue");
        //获取链接url获取的返回码
        int requestCode = httpURLConnection.getResponseCode();
        if(requestCode == 200){//表示我们请求成功
            /**
             * 然后获取流读取数据,这样基本就完成了一个Get的请求方式。
             */
        }

    (2)、HttpURLConnection的”POST”方式:
    这种方式下就和”GET”方式有所不同,”GET”请求我们直接把数据放在url地址的后面,而”POST”请求时,我们将数据放到了http的body里面,所以这里需要我们多设置两个方法。

    • httpUrlConnection.setDoOutput(boolean):使用 URL 连接进行输出,则将 DoOutput 标志设置为 true;如果不打算使用,则设置为 false。默认值为 false。
    • httpUrlConnection.setDoInput(boolean):使用 URL 连接进行输入,则将 DoInput 标志设置为 true;如果不打算使用,则设置为 false。默认值为 true。

    实际开发中:

        httpUrlConnection.setDoOutput(true);以后就可以使用conn.getOutputStream().write(),向服务器写数据 ,即我们俗称向后台发送数据。
        httpUrlConnection.setDoInput(true);以后就可以使用conn.getInputStream().read(),读取服务器端数据
    • get请求用不到conn.getOutputStream(),因为参数直接追加在地址后面,因此默认是false。
    • post请求(比如:文件上传)需要往服务区传输大量的数据,这些数据是放在http的body里面的,因此需要在建立连接以后,往服务端写数据。

    因为总是使用conn.getInputStream()获取服务端的响应,因此默认值是true。

    下面看一个实例:

        //建立一个URL对象
        URL url = new URL("http://blog.csdn.net/mr_dsw");
        //获取HttpURLConnection对象
        HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
        httpURLConnection.setConnectTimeout(2000);
        //设置请求方式
        httpURLConnection.setRequestMethod("POST");
        //设置读取数据的时间
        httpURLConnection.setReadTimeout(2000);
        //设置是否使用缓存
        httpURLConnection.setUseCaches(false);
        //设置可以从服务器读取数据,默认为true
        httpURLConnection.setDoInput(true);
        //设置可以向服务器发送数据,默认为false
        httpURLConnection.setDoOutput(true);
        OutputStream outputStream = httpURLConnection.getOutputStream();
        outputStream.write("发送到服务器数据".getBytes());
        //设置长连接
        httpURLConnection.setRequestProperty("Connection","Keep-Alive");
        //设置数据格式
        httpURLConnection.setRequestProperty("Charset", "UTF-8");
        //设置长度
        httpURLConnection.setRequestProperty("Content-Length", String.valueOf("发送到服务器数据"));
        //设置文件类型
        httpURLConnection.setRequestProperty("Content-Type","application/x-www-form-urlencoded");
        //获取链接url获取的返回码
        int requestCode = httpURLConnection.getResponseCode();
        if(requestCode == 200){//表示我们请求成功
            /**
             * 然后获取流读取数据,这样基本就完成了一个Get的请求方式。
             */
        }

    补充知识点:

    (1)、http请求头

    Header解释示例
    Accept指定客户端能够接收的内容类型Accept: text/plain, text/html
    Accept-Charset浏览器可以接受的字符编码集。Accept-Charset: iso-8859-5
    Accept-Encoding指定浏览器可以支持的web服务器返回内容压缩编码类型。Accept-Encoding: compress, gzip
    Accept-Language浏览器可接受的语言Accept-Language: en,zh
    Accept-Ranges可以请求网页实体的一个或者多个子范围字段Accept-Ranges: bytes
    AuthorizationHTTP授权的授权证书Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
    Cache-Control指定请求和响应遵循的缓存机制Cache-Control: no-cache
    Connection表示是否需要持久连接。(HTTP 1.1默认进行持久连接)Connection: close
    CookieHTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器。Cookie: $Version=1; Skin=new;
    Content-Length请求的内容长度Content-Length: 348
    Content-Type请求的与实体对应的MIME信息Content-Type: application/x-www-form-urlencoded
    Date请求发送的日期和时间Date: Tue, 15 Nov 2010 08:12:31 GMT
    Expect请求的特定的服务器行为Expect: 100-continue
    From发出请求的用户的EmailFrom: user@email.com
    Host指定请求的服务器的域名和端口号Host: www.zcmhi.com
    If-Match只有请求内容与实体相匹配才有效If-Match: “737060cd8c284d8af7ad3082f209582d”
    If-Modified-Since如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
    If-None-Match如果内容未改变返回304代码,参数为服务器先前发送的Etag,与服务器回应的Etag比较判断是否改变If-None-Match: “737060cd8c284d8af7ad3082f209582d”
    If-Range如果实体未改变,服务器发送客户端丢失的部分,否则发送整个实体。参数也为EtagIf-Range: “737060cd8c284d8af7ad3082f209582d”
    If-Unmodified-Since只在实体在指定时间之后未被修改才请求成功If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
    Max-Forwards限制信息通过代理和网关传送的时间Max-Forwards: 10
    Pragma用来包含实现特定的指令Pragma: no-cache
    Proxy-Authorization连接到代理的授权证书Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
    Range只请求实体的一部分,指定范围Range: bytes=500-999
    Referer先前网页的地址,当前请求网页紧随其后,即来路Referer: http://www.zcmhi.com/archives/71.html
    TE客户端愿意接受的传输编码,并通知服务器接受接受尾加头信息TE: trailers,deflate;q=0.5
    Upgrade向服务器指定某种传输协议以便服务器进行转换(如果支持)Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    User-AgentUser-Agent的内容包含发出请求的用户信息User-Agent: Mozilla/5.0 (Linux; X11)
    Via通知中间网关或代理服务器地址,通信协议Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
    Warning关于消息实体的警告信息Warn: 199 Miscellaneous warning

    (2)、状态码
    (2.1)常见状态码

    • 200 - 请求成功
    • 301 - 资源(网页等)被永久转移到其它URL
    • 404 - 请求的资源(网页等)不存在
    • 500 - 内部服务器错误

    (2.2)HTTP状态码的分

    分类分类描述
    1**信息,服务器收到请求,需要请求者继续执行操作
    2**成功,操作被成功接收并处理
    3**重定向,需要进一步的操作以完成请求
    4**客户端错误,请求包含语法错误或无法完成请求
    5**服务器错误,服务器在处理请求的过程中发生了错误

    (3)、状态码详解

    状态码含义
    100客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。
    101服务器已经理解了客户端的请求,并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后,服务器将会切换到在Upgrade 消息头中定义的那些协议。   只有在切换新的协议更有好处的时候才应该采取类似措施。例如,切换到新的HTTP 版本比旧版本更有优势,或者切换到一个实时且同步的协议以传送利用此类特性的资源。
    102由WebDAV(RFC 2518)扩展的状态码,代表处理将被继续执行。
    200请求已成功,请求所希望的响应头或数据体将随此响应返回。
    201请求已经被实现,而且有一个新的资源已经依据请求的需要而建立,且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话,应当返回 ‘202 Accepted’。
    202服务器已接受请求,但尚未处理。正如它可能被拒绝一样,最终该请求可能会也可能不会被执行。在异步操作的场合下,没有比发送这个状态码更方便的做法了。   返回202状态码的响应的目的是允许服务器接受其他过程的请求(例如某个每天只执行一次的基于批处理的操作),而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息,以及指向处理状态监视器或状态预测的指针,以便用户能够估计操作是否已经完成。
    203服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合,而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如,包含资源的元数据可能导致原始服务器知道元信息的超级。使用此状态码不是必须的,而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。
    204服务器成功处理了请求,但不需要返回任何实体内容,并且希望返回更新了的元信息。响应可能通过实体头部的形式,返回新的或更新后的元信息。如果存在这些头部信息,则应当与所请求的变量相呼应。   如果客户端是浏览器的话,那么用户浏览器应保留发送了该请求的页面,而不产生任何文档视图上的变化,即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。   由于204响应被禁止包含任何消息体,因此它始终以消息头后的第一个空行结尾。
    205服务器成功处理了请求,且没有返回任何内容。但是与204响应不同,返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后,立即重置表单,以便用户能够轻松地开始另一次输入。   与204响应一样,该响应也被禁止包含任何消息体,且以消息头后的第一个空行结束。
    206服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。   该请求必须包含 Range 头信息来指示客户端希望得到的内容范围,并且可能包含 If-Range 来作为请求条件。   响应必须包含如下的头部域:   Content-Range 用以指示本次响应中返回的内容的范围;如果是 Content-Type 为 multipart/byteranges 的多段下载,则每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围。假如响应中包含 Content-Length,那么它的数值必须匹配它返回的内容范围的真实字节数。   Date   ETag 和/或 Content-Location,假如同样的请求本应该返回200响应。   Expires, Cache-Control,和/或 Vary,假如其值可能与之前相同变量的其他响应对应的值不同的话。   假如本响应请求使用了 If-Range 强缓存验证,那么本次响应不应该包含其他实体头;假如本响应的请求使用了 If-Range 弱缓存验证,那么本次响应禁止包含其他实体头;这避免了缓存的实体内容和更新了的实体头信息之间的不一致。否则,本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。   假如 ETag 或 Last-Modified 头部不能精确匹配的话,则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起。   任何不支持 Range 以及 Content-Range 头的缓存都禁止缓存206响应返回的内容。
    207由WebDAV(RFC 2518)扩展的状态码,代表之后的消息体将是一个XML消息,并且可能依照之前子请求数量的不同,包含一系列独立的响应代码。
    300被请求的资源有一系列可供选择的回馈信息,每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。   除非这是一个 HEAD 请求,否则该响应应当包括一个资源特性及地址的列表的实体,以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由 Content-Type 定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力,自动作出最合适的选择。当然,RFC 2616规范并没有规定这样的自动选择该如何进行。   如果服务器本身已经有了首选的回馈选择,那么在 Location 中应当指明这个回馈的 URI;浏览器可能会将这个 Location 值作为自动重定向的地址。此外,除非额外指定,否则这个响应也是可缓存的。
    301被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能,拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定,否则这个响应也是可缓存的。   新的永久性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。   如果这不是一个 GET 或者 HEAD 请求,因此浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。   注意:对于某些使用 HTTP/1.0 协议的浏览器,当它们发送的 POST 请求得到了一个301响应的话,接下来的重定向请求将会变成 GET 方式。
    302请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。   新的临时性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。   如果这不是一个 GET 或者 HEAD 请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。   注意:虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法,但是很多现存的浏览器将302响应视作为303响应,并且使用 GET 方式访问在 Location 中规定的 URI,而无视原先请求的方法。状态码303和307被添加了进来,用以明确服务器期待客户端进行何种反应。
    303对应当前请求的响应可以在另一个 URI 上被找到,而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时,303响应禁止被缓存。当然,第二个请求(重定向)可能被缓存。   新的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。   注意:许多 HTTP/1.1 版以前的 浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动,302状态码应该可以胜任,因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。
    304如果客户端发送了一个带条件的 GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回这个状态码。304响应禁止包含消息体,因此始终以消息头后的第一个空行结尾。   该响应必须包含以下的头信息:   Date,除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则,那么代理服务器以及客户端可以自行将 Date 字段添加到接收到的响应头中去(正如RFC 2068中规定的一样),缓存机制将会正常工作。   ETag 和/或 Content-Location,假如同样的请求本应返回200响应。   Expires, Cache-Control,和/或Vary,假如其值可能与之前相同变量的其他响应对应的值不同的话。   假如本响应请求使用了强缓存验证,那么本次响应不应该包含其他实体头;否则(例如,某个带条件的 GET 请求使用了弱缓存验证),本次响应禁止包含其他实体头;这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。   假如某个304响应指明了当前某个实体没有缓存,那么缓存系统必须忽视这个响应,并且重复发送不包含限制条件的请求。   假如接收到一个要求更新某个缓存条目的304响应,那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段的值。
    305被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息,接收者需要重复发送一个单独的请求,通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。   注意:RFC 2068中没有明确305响应是为了重定向一个单独的请求,而且只能被原始服务器建立。忽视这些限制可能导致严重的安全后果。
    306在最新版的规范中,306状态码已经不再被使用。
    307请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。   新的临时性的URI 应当在响应的 Location 域中返回。除非这是一个HEAD 请求,否则响应的实体中应当包含指向新的URI 的超链接及简短说明。因为部分浏览器不能识别307响应,因此需要添加上述必要信息以便用户能够理解并向新的 URI 发出访问请求。   如果这不是一个GET 或者 HEAD 请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。
    4001、语义有误,当前请求无法被服务器理解。除非进行修改,否则客户端不应该重复提交这个请求。   2、请求参数有误。
    401当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书,那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问,且浏览器已经至少尝试了一次验证,那么浏览器应当向用户展示响应中包含的实体信息,因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。
    402该状态码是为了将来可能的需求而预留的。
    403服务器已经理解请求,但是拒绝执行它。与401响应不同的是,身份验证并不能提供任何帮助,而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求,而且服务器希望能够讲清楚为何请求不能被执行,那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应,假如它不希望让客户端获得任何信息。
    404请求失败,请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话,应当使用410状态码来告知旧资源因为某些内部的配置机制问题,已经永久的不可用,而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
    405请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。   鉴于 PUT,DELETE 方法会对服务器上的资源进行写操作,因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法,对于此类请求均会返回405错误。
    406请求的资源的内容特性无法满足请求头中的条件,因而无法生成响应实体。   除非这是一个 HEAD 请求,否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由 Content-Type 头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是,规范中并没有定义任何作出此类自动选择的标准。
    407 与401响应类似,只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。参见RFC 2617。
    408请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。
    409由于和被请求的资源的当前状态之间存在冲突,请求无法完成。这个代码只允许用在这样的情况下才能被使用:用户被认为能够解决冲突,并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。   冲突通常发生于对 PUT 请求的处理中。例如,在采用版本检查的环境下,某次 PUT 提交的对特定资源的修改请求所附带的版本信息与之前的某个(第三方)请求向冲突,那么此时服务器就应该返回一个409错误,告知用户请求无法完成。此时,响应实体中很可能会包含两个冲突版本之间的差异比较,以便用户重新提交归并以后的新版本。
    410被请求的资源在服务器上已经不再可用,而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能,拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的,那么就应该使用404状态码。除非额外说明,否则这个响应是可缓存的。   410响应的目的主要是帮助网站管理员维护网站,通知用户该资源已经不再可用,并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样,410响应也被用于通知客户端在当前服务器站点上,原本属于某个个人的资源已经不再可用。当然,是否需要把所有永久不可用的资源标记为’410 Gone’,以及是否需要保持此标记多长时间,完全取决于服务器拥有者。
    411服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后,客户端可以再次提交该请求。
    412服务器在验证在请求的头字段中给出先决条件时,没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息(请求头字段数据)中设置先决条件,以此避免该请求方法被应用到其希望的内容以外的资源上。
    413服务器拒绝处理当前请求,因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下,服务器可以关闭连接以免客户端继续发送此请求。   如果这个状况是临时的,服务器应当返回一个 Retry-After 的响应头,以告知客户端可以在多少时间以后重新尝试。
    414请求的URI 长度超过了服务器能够解释的长度,因此服务器拒绝对该请求提供服务。这比较少见,通常的情况包括:   本应使用POST方法的表单提交变成了GET方法,导致查询字符串(Query String)过长。   重定向URI “黑洞”,例如每次重定向把旧的 URI 作为新的 URI 的一部分,导致在若干次重定向后 URI 超长。   客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的 URI,当 GET 后的参数超过某个数值后,可能会产生缓冲区溢出,导致任意代码被执行[1]。没有此类漏洞的服务器,应当返回414状态码。
    415对于当前请求的方法和所请求的资源,请求中提交的实体并不是服务器中所支持的格式,因此请求被拒绝。
    416如果请求中包含了 Range 请求头,并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合,同时请求中又没有定义 If-Range 请求头,那么服务器就应当返回416状态码。   假如 Range 使用的是字节范围,那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时,包含一个 Content-Range 实体头,用以指明当前资源的长度。这个响应也被禁止使用 multipart/byteranges 作为其 Content-Type。
    417在请求头 Expect 中指定的预期内容无法被服务器满足,或者这个服务器是一个代理服务器,它有明显的证据证明在当前路由的下一个节点上,Expect 的内容无法被满足。
    421从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常,这里的IP地址指的是从服务器上看到的客户端地址(比如用户的网关或者代理服务器地址)。在这种情况下,连接数的计算可能涉及到不止一个终端用户。
    422从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常,这里的IP地址指的是从服务器上看到的客户端地址(比如用户的网关或者代理服务器地址)。在这种情况下,连接数的计算可能涉及到不止一个终端用户。
    422请求格式正确,但是由于含有语义错误,无法响应。(RFC 4918 WebDAV)423 Locked   当前资源被锁定。(RFC 4918 WebDAV)
    424由于之前的某个请求发生的错误,导致当前请求失败,例如 PROPPATCH。(RFC 4918 WebDAV)
    425在WebDav Advanced Collections 草案中定义,但是未出现在《WebDAV 顺序集协议》(RFC 3658)中。
    426客户端应当切换到TLS/1.0。(RFC 2817)
    449由微软扩展,代表请求应当在执行完适当的操作后进行重试。
    500服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。一般来说,这个问题都会在服务器的程序码出错时出现。
    501服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法,并且无法支持其对任何资源的请求。
    502作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
    503由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的,并且将在一段时间以后恢复。如果能够预计延迟时间,那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息,那么客户端应当以处理500响应的方式处理它。   注意:503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。
    504作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。   注意:某些代理服务器在DNS查询超时时会返回400或者500错误
    505服务器不支持,或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。
    506由《透明内容协商协议》(RFC 2295)扩展,代表服务器存在内部配置错误:被请求的协商变元资源被配置为在透明内容协商中使用自己,因此在一个协商处理中不是一个合适的重点。
    507服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV (RFC 4918)
    509服务器达到带宽限制。这不是一个官方的状态码,但是仍被广泛使用。
    510获取资源所需要的策略并没有没满足。(RFC 2774)

    至此,基于HttpURLConnection的知识点讲解完毕,后续会有实战。

    基于HttpClient

    这点我就不深入说了,直接看两个用法案例吧!

    (1)”GET”请求方式

    get

    (2)”POST”请求方式

    post

    至此,关于基础知识已经讲解完毕,后面我们就会进行练习他们的使用。

    作者:mr_dsw 欢迎转载,与人分享是进步的源泉!

    转载请保留地址:http://blog.csdn.net/mr_dsw

    展开全文
  • Python3 urllib(网络数据获取 模块)

    万次阅读 2017-04-10 02:22:00
    Python3 urllib(网络数据获取 模块) 本文由 Luzhuo 编写,转发请保留该信息. 原文: http://blog.csdn.net/Rozol/article/details/69941511 以下代码以Python3.6.1为例 Less is more! #coding=utf-8 ...
  • 网络爬虫中我们经常需要设置一些头部信息,使我们进行网页抓取的行为更加像浏览器的行为,并且我们有时需要将头部信息设置正确,才能得到正确的数据,要不然有可能得到和浏览器所展示的页面有出入的信息。...
  • 网络数据截获方法

    千次阅读 2004-07-03 15:12:00
    网络数据截获方法作者:浩海孤帆@bbs.net130.com网络数据截获方法网络数据包截获机制是网络入侵检测系统的基础组件。一般指通过截获整个网络的所有信息流量,根据信息源主机,目标主机,服务协议端口等信息简单过滤...
  • 【以太网数据结构】以太网头部

    千次阅读 2015-11-24 17:14:03
    以太网封包格式如图所示: 以太网目的地址和源地址各占6个字节,该...类型字段之后是数据,对于以太网,数据段大小为46-1500字节,不足46字节的数据将被自动补足到46字节。如ARP协议的数据格式为28字节,为了符
  • 如何 post json格式的数据,并附加http,接受返回数据,请看下面的代码: private void HttpPostData() { try { HttpClient httpclient = new DefaultHttpClient(); String
  • 计算机网络数据是如何传输的?

    万次阅读 2019-05-28 17:33:29
    计算机网络是个非常复杂的系统,两个相互通信的计算机必须要能高度协调工作。而且不同网络体系结构的用户都需要通信,而且要做到在全世界范围的计算机都可以高效进行通信。于是OSI(Open Systems Interconnection ...
  •  消息(并不是每一次请求都一样)  空行  内容(内容名字=内容体) 常用消息(详解http请求消息)  Accept:text/html,image/*(告诉服务器,浏览器可以接受文本,网页图片)  Accept-Chara
  • 深度神经网络有一个大问题-他们一直渴望数据。 当数据太少时(无法到达算法可以接受的数量)深度神经网络很难推广。 这种现象突出了人类和机器认知之间的差距。 人们可以通过很少的训练示例来学习复杂的模式(尽管...
  • P2P网络数据交互

    千次阅读 2018-08-28 17:03:08
    1. 发送交易数据SendTransactions 事件触发交易广播txBroadcastLoop 本地发送了一个交易,或者是接收到别人发来的交易信息。 txpool会产生一条消息,消息被传递到txCh通道。然后被goroutine txBroadcastLoop()处理...
  • 打开网页源代码network下的doc查看请求与响应信息
  • 1.用户数据报协议(User Datagram Protocol)简称UDP协议,它是在IP的数据报服务上增加了端口和简单的差错检测来实现进程到进程之间的数据传输。 2.UDP协议有如下几个特点: a.无连接。UDP是无连接的协议,数据传输...
  • 我们在进行网络请求的时候,服务器是如何知道我们的手机类型和信息呢?这些信息是通过请求头部发送的。关于如何导入AFNetworking库,请查看我的另一篇博客《》
  • 客户端给服务器发送请求服务器给客户端发送响应package com.example.httpdemo;import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader;...
  • iOS 网络请求及数据解析

    千次阅读 2016-03-15 09:14:42
    iOS 网络请求,数据解析
  • 以太坊:P2P网络数据交互

    万次阅读 2019-04-14 00:07:57
    P2P网络数据交互 1. 发送交易数据SendTransactions 事件触发交易广播txBroadcastLoop 本地发送了一个交易,或者是接收到别人发来的交易信息。 txpool会产生一条消息,消息被传递到txCh通道。然后被goroutine ...
  • 2.6 HTTP信息头

    千次阅读 2020-06-30 23:18:51
    只有在消息中包含实体数据时,实体才会出现。HTTP信息头是由头字段和字段值组成的,如下图所示。 1.通用 通用既可以在请求信息中出现也可以在响应信息中出现,其提供了与报文相关的基本信息。下面列出了HTTP...
  • 计算机网络3 数据链路层

    千次阅读 多人点赞 2020-09-17 09:53:34
    数据链路层属于计算机网络的低层,主要使用: 点对点信道:一对一的点对点通信方式,点对点协议PPP 广播信道:一对多的广播通信方式,CSMA/CD协议 数据链路和帧 链路(link):从一个结点到相邻结点的一段物理...
  • 云计算数据中心网络的关键技术

    千次阅读 2012-05-01 16:59:33
    云计算数据中心网络的关键技术 发表时间:2012-4-24 黄大川 来源:万方数据 关键字:云计算 面向服务的架构 虚拟化 数据中心以太网 信息化调查找茬投稿收藏评论好文推荐打印社区分享 简要介绍了...
  • 网络数据传输的封装

    千次阅读 2016-03-31 15:43:20
    数据封装(Data Encapsulation)是指将协议数据单元(PDU)封装在一组协议和尾中的过程。在OSI七层参考模型中,每层主要负责与其它机器上的对等层进行通信。该过程是在协议数据单元(PDU)中实现的,其中每层的PDU...
  • 作者:Melo Chale 转载请注明出处!...运营商在带宽增加的同时没有正比的增加相应的收益,所以他们需要对各种网络数据进行分析之后,在网关或者服务器上进行优化后再传输,提高带宽利用率。要对数据进行分析,首
  • 命名数据网络(NDN)与TCP/IP网络

    万次阅读 2015-10-17 13:23:16
    当时没有回答好,然后提到了NDN可以针对TCP/IP做出改进,但是在行家面前就漏洞百出,一是对TCP/IP网络理解不够深入,另外一方面是自己对NDN比较陌生。趁着这段时间比较得闲,在网上搜了《Named Data Networking(NDN)...
  • Python网络数据采集(爬虫)

    万次阅读 多人点赞 2017-10-15 09:07:04
    网络数据采集程序也像是一只辛勤采蜜的小蜜蜂,它飞到花(目标网页)上,采集花粉(需要的信息),经过处理(数据清洗、存储)变成蜂蜜(可用的数据)。 思考“网络爬虫”时通常的想法: (就是自己写api)  •...
  • 计算机网络---数据成帧

    千次阅读 2012-04-20 18:31:29
    其中,帧和帧尾包含一些必要得控制信息,比如同步信息、地址信息、差错控制信息等; 数据部分则包含网络层传下来的数据,比如ip数据报。 数据组合成数据块,在数据链路层中称这种数据块为帧(frame),帧...
  • 《计算机网络》第3章 数据链路层

    万次阅读 多人点赞 2017-03-23 16:33:13
    数据链路层使用物理层提供的服务在通信信道上发送和接收比特。 功能包括: (1) 向网络层提供一个定义良好的接口 (2) 处理传输错误 (3) 调节数据流,确保慢速的接收方不会被快速的发送方淹没
  • 以太坊:P2P网络数据处理流程

    万次阅读 2019-04-14 00:07:45
    P2P网络数据处理流程 监听(ListenLoop)+拨号(Dial) –> 建立连接(SetupConn) –> Enc 握手(doEncHandshake) –> 协议握手(doProtoHandshake) –> 添加Peer Addpeer –> Run Peer 1. Enc握手 ...
  • 本博文较为详细的介绍数据链路层的各个方面。在网络协议中的位置及其作用,包括数据帧封装,差错检测...并涉及到网络协议各层的数据封装以及网络通信中数据传输通道的简要分析。这算是对数据链路层的一个详细的学习笔记

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 408,205
精华内容 163,282
关键字:

网络数据头信息