DW里站点URL是什么，服务器里连接方式（本地网络）这个是什么意思怎么用谢谢各位。

本地网络指的就是在你的电脑内浏览或测试网页，不连接到因特网。如果你制作的是静态网页选择本地网络，就不需要填写下面的web url，如果你制作的是诸如php这样的程序，则需要安装网络服务器之后，再填写web url，上的web url就是网络服务器默认的主页地址。

http:// 代表服务器使用的是HTTP通信协议

10022 代表服务器的ip地址

8080 代表服务器监听的端口号

/article/JSONDemoServlet 是服务器程序配置的，那里有一个webxml文件，里面配置的是这个路径和Servlet之间的映射关系，所以/article/JSONDemoServlet和目录是没有关系的，它只是一个字符串，起到一个索引的作用，如果不写全是访问不到指定的Servlet的

前三个可以说是服务器程序的外部环境，第四个是服务器程序的内部环境

URL是Uniform Resource Locator的缩写，即统一资源定位器，它是一个识别Internet中哪里有信息资源，并且将Internet提供的服务统一编址的系统。通过URL可以到达任何一个地方寻找需要的东西，比如文件、数据库、图像、新闻组等等，可以这样说，URL是Internet上的地址簿。URL一般由三个部分构成，各个部分如下： 1 服务器标识符 通过选择服务器标识符能够确定将要访问的服务器的类型，URL中的服务器标识符可以有http://、FTP://、GOPHER://、TELNET://、NWES://等等类型，分别指定为采用超文本传输协议连接、采用文件传输协议连接、与GOPHER服务器连接、与TELNET会话连接、与USENET新闻组相连接。 2 信息资源地址 信息资源地址是由两部分构成的，一是机器名称，如wwwtsinghuaeducn是用来指示资源所存在的机器，另一个是通信端口号（port number），是连接时所使用的通信端口号。端口是Internet用来辨别特定信息服务用的一种软件标识，其设置范围是0到65535之间的整数，一般情况下使用的是标准端口号，可以不用写出。在需要特殊服务时会用到非标准端口号，这时就要写出，如http://wwwtsinghuaeducn:81。常见的Internet提供服务的端口号，如HTTP的标准端口号为80，TELNET的标准端口号为23，FTP的标准端口号为21等等。 3 路径名 路径名是给出资源在所在机器上的完整文件名，一般情况下只有用户知道所要找的资源在什么地方时才会给出这个选项。如http://wwwtsinghuaeducn/indexhtml等。

url简单说就是网址

URL

全球资源定位器 n [电脑网路]

URL（Uniform Resource Locator）中文名称是「全球资源定位器」，也被翻译做「通用资源位标」，是也就是一个位址，可单独识别网际网路上的电脑、目录或档案位置，也可以指定通讯协定，例如 Gopher、HTTP 等等。URL能让在Internet上的所有资源都能透过此的方法而找到其位置。

URL的介绍

在WWW（全球资讯网）中想要连结到某个网页，便需要给浏览器一个位址，而URL在此的功能就是告知浏览器某个资源在那个位置，简单来说，通常我们在IE或Netscape浏览器中所输入的网址就是URL的其中一种。

HTTP（Hypertext Transfer Protocol）超文字传输通讯协定是WWW中伺服器和浏览器最主要的沟通方式，而为了能让浏览器正确的在网路上找资料的位置，於是便以URL的方式使浏览器确定某一资源的位置。通常URL不一定是指向一份超媒体文件，它也可以是某种网路上的服务，如Ftp、Gopher等。

URL的格式

URL是以「://」为区隔，举例来说，「http://wwwdreyecom/」这个网址，「://」之前的「http」便是Protocol（传输或通讯协定)，而之后的「wwwdreyecom」所指的便是伺服器的位址，其中「www」便是「World Wide Web」，而「dreye」是此站的名称，而「com」所指的是「网域类型」，由於受限於DNS的型式，所以其中需以「」点分开；通常还会在后面加上「国别」（如台湾便是tw）而组成最基本URL的格式：「Protocol://连结类型站名网域类型国别」。

在Protocol（传输或通讯协定)方面有http、ftp、telnet、gopher等不同的服务，而网域类型也有许多归类，如com是商业组织、edu是教育机构、gov是政府、mil是军方的网站、net是网路服务公司等。

由以上的URL方式，网路便可一一被定址出来、归类出来，浏览器也就能够正确的找到位置；URL不一定都是英文字，再怎麼长的网址都可被转换成4组数字。

而近来已有所谓中文网址的出现，此项技术的出现也打破了以往URL的限制，让网路搜寻资源更加快速、更容易被接受与记忆。

参考http://zhidaobaiducom/question/22917211htmlsi=1

编辑个人资料，在编辑url，有个框框你输入你想输入的字母数字都可以。

Steam是一个整合游戏下载平台。2002年，Steam系统与CS14 Beta一起问世。至目前为止，Steam的运作十分成功广泛，无数游戏发行公司的游戏在此平台上发行、更新。

Steam英文原译为蒸汽。至于为什么叫“Steam”。在Steam平台上下载游戏的速度是非常快的，速度快得就像蒸汽一样喷薄而出，令人难以置信，所以名曰Steam。一般情况下可达到满速，目前有7个国内下载点可以使用。

一、前言

前几天整理面试题的时候，有一道试题是《如何将一个很长的URL转换为一个短的URL，并实现他们之间的相互转换？》，现在想起来这是一个绝对不简单的问题，需要考虑很多方面，今天和大家一起学习研究一下！

短网址：顾名思义，就是将长网址缩短到一个很短的网址，用户访问这个短网址可以重定向到原本的长网址（也就是还原的过程）。这样可以达到易于记忆、转换的目的，常用于有字数限制的微博、二维码等等场景。

关于短URL的使用场景，举个简单的例子来说明一下，看一下业务中使用短URL的重要性！

二、短地址使用场景

1、新浪微博

我们在新浪微博上发布网址的时候，微博会自动判别网址，并将其转换，例如：https://tcn/RuPKzRW。为什么要这样做的？

这是因为微博限制字数为140字一条，那么如果我们需要发一些链接上去，但是这个链接非常的长，以至于将近要占用我们内容的一半篇幅，这肯定是不能被允许的或者说用户体验很差的，所以短网址应运而生了，短网址这种服务可以说是在微博出现之后才流行开来的！往下看：

（1）首先，我先发一条微博带有一个URL地址：

（2）然后，看他转换之后显示的效果是什么样子的哪？

（3）查看对应页面元素的HTML源码如下：

（4）可以看出：https://blogcsdnnet/xlgen157387/article/details/79863301 被转换为：http://tcn/RuPKzRW，此时你访问http://tcn/RuPKzRW是可以定位到https://blogcsdnnet/xlgen157387/article/details/79863301，也就是实现了转换。

2、短网址二维码

网址在转换成短网址时，也可以生成相应的短网址二维码，短网址二维码的应用，二维码核心解决的是跨平台、跨现实的数据传输问题；而且二维码跟应用场景结合之后，所能解决的问题会越来越多。

（1）短网址二维码相比短链接更方便，能少输入，尽量少输入，哪怕只是少点一下键盘，都是有意义的。

（2）二维码只是扫描一个简单的链接，打开的却是一个世界。想象一下，用手机购买售货机里商品，二维码扫描是略快于从用手机找到该售货机并找到该商品的，而且这种操作相对于搜索/查找而言不是更优雅吗

（3）所有商超里面的商品，都是使用条码来确定商品的唯一性的，去买单的时候都是扫描条码。试想，如果里面加入了更多产品的生产日期、厂家、流转途径、原材料等等信息，是不是厉害了呢特别是针对食品信息的可追溯上，二维码应用场景更广泛。

三、短地址的好处

除了上述场景中，我们将长地址转换为短地址的使用场景的优点（压缩URL长度）之外，短地址还具有很多实际场景中的优点，例如：

（1）节省网址长度，便于社交化传播，一个是让URL更短小，传播更方便，尤其是URL中有中文和特殊字符，短网址解决很长的URL难以记忆不利于传播的问题；

（2）短网址在我们项目里可以很好的对开放以及对URL进行管理。有一部分网址可以会涵盖性、暴力、广告等信息，这样我们可以通过用户的举报，完全管理这个连接将不出现在我们的应用中，对同样的URL通过加密算法之后，得到的地址是一样的；

（3）方便后台跟踪点击量、地域分布等用户统计。我们可以对一系列的网址进行流量，点击等统计，挖掘出大多数用户的关注点，这样有利于我们对项目的后续工作更好的作出决策；

（4）规避关键词、域名屏蔽手段、隐藏真实地址，适合做付费推广链接；

（5）当你看到一个淘宝的宝贝连接后面是200个“e7x8bv7c8bisdj”这样的字符的时候，你还会觉得舒服吗。更何况微博字数只有140字，微博或短信里，字数不够，你用条短网址就能帮你腾出很多空间来；

四、短网址服务提供平台

目前，国内网又很多提供短地址服务的平台，例如：

新浪：http://sinalt/

百度：http://dwzcn/

0x3：http://0x3me/

MRW：http://mrwso/

等等还有很多，这个可以搜索一下就会有很多！但是一个注意的是，如果使用某一个平台的短地址服务，一定要保证长期可靠的服务，不然一段时间失效了，我们以前已经转换的URL就完了！

这里以百度例，将我们上述博客的地址转换为短地址如下所示：

当然，对于我们的业务来说，如果自己可以提供自己的短URL服务那才是更好的，不需要受制于人！（中国芯片需要崛起！！！）

五、关于如何生成短地址URL的讨论

关于短地址URL如何生成方式的，网上有很多方式，有基于映射的，有基于Hash的，有基于签名的，但是总的来说并不能满足绝大部分场景的使用，或者说是一种错误的设计方式。这里不再重复造轮子！以下是知乎用户iammutex关于该问题的探讨，截图过来和大家一起学习一下：

作者：iammutex

链接：https://wwwzhihucom/question/29270034/answer/46446911

来源：知乎

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

六、生成短地址URL需要注意的

看到上述知乎用户iammutex关于如何正确生成短地址URL的探讨，我们知道了，可以通过发号器的方式正确的生成短地址，生成算法设计要点如下：

（1）利用放号器，初始值为0，对于每一个短链接生成请求，都递增放号器的值，再将此值转换为62进制（a-zA-Z0-9），比如第一次请求时放号器的值为0，对应62进制为a，第二次请求时放号器的值为1，对应62进制为b，第10001次请求时放号器的值为10000，对应62进制为sBc。

（2）将短链接服务器域名与放号器的62进制值进行字符串连接，即为短链接的URL，比如：http://tcn/sBc。

（3）重定向过程：生成短链接之后，需要存储短链接到长链接的映射关系，即sBc -> URL，浏览器访问短链接服务器时，根据URL Path取到原始的链接，然后进行302重定向。映射关系可使用K-V存储，比如Redis或Memcache。

七、生成短地址之后如何跳转哪？

对于该部分的讨论，我们可以认为他是整个交互的流程，具体的流程细节如下：

（1）用户访问短链接：http://tcn/RuPKzRW；

（2）短链接服务器http://tcn收到请求，根据URL路径RuPKzRW获取到原始的长链接（KV缓存数据库中去查找）：https://blogcsdnnet/xlgen157387/article/details/79863301；

（3）服务器返回302状态码，将响应头中的Location设置为：https://blogcsdnnet/xlgen157387/article/details/79863301；

（4）浏览器重新向https://blogcsdnnet/xlgen157387/article/details/79863301发送请求；

（5）返回响应；

八、短地址发号器优化方案

1、算法优化

采用以上算法，如果不加判断，那么即使对于同一个原始URL，每次生成的短链接也是不同的，这样就会浪费存储空间（因为需要存储多个短链接到同一个URL的映射），如果能将相同的URL映射成同一个短链接，这样就可以节省存储空间了。主要的思路有如下两个：

方案1：查表

每次生成短链接时，先在映射表中查找是否已有原始URL的映射关系，如果有，则直接返回结果。很明显，这种方式效率很低。

方案2：使用LRU本地缓存，空间换时间

使用固定大小的LRU缓存，存储最近N次的映射结果，这样，如果某一个链接生成的非常频繁，则可以在LRU缓存中找到结果直接返回，这是存储空间和性能方面的折中。

2、可伸缩和高可用

如果将短链接生成服务单机部署，缺点一是性能不足，不足以承受海量的并发访问，二是成为系统单点，如果这台机器宕机则整套服务不可 用，为了解决这个问题，可以将系统集群化，进行“分片”。

在以上描述的系统架构中，如果发号器用Redis实现，则Redis是系统的瓶颈与单点，因此，利用数据库分片的设计思想，可部署多个发号器实例，每个实例负责特定号段的发号，比如部署10台Redis，每台分别负责号段尾号为0-9的发号，注意此时发号器的步长则应该设置为10（实例个数）。

另外，也可将长链接与短链接映射关系的存储进行分片，由于没有一个中心化的存储位置，因此需要开发额外的服务，用于查找短链接对应的原始链接的存储节点，这样才能去正确的节点上找到映射关系。

九、如何用代码实现短地址

1、使用随机序列生成短地址

说到这里终于说到重点了，很多小伙伴已经按捺不住了，不好意思让大家失望了，这只是一片简单的文章，并不能把这么繁杂的一个系统演示清楚！秉着不要重复造轮子的原则，这里给出一个为数不多还算可以的实现短地址的开源项目：urlshorter

注意：urlshorter本身还是基于随机的方式生成短地址的，并不算是一个短地址发号器，因此会有性能问题和冲突的出现，和知乎用户iammutex 描述的实现方式还是有区别的！而关于短地址发号器的方式目前还没有找到更好的开源项目可供参考！

项目地址：https://giteecom/tinyframework/urlshorter

2、使用SnowFlake发号器生成短地址

实现参考： https://githubcom/beyondfengyu/SnowFlake http://wwwwolfbecom/detail/201611/381html

Twitter的雪花算法SnowFlake，使用Java语言实现。

SnowFlake算法用来生成64位的ID，刚好可以用long整型存储，能够用于分布式系统中生产唯一的ID， 并且生成的ID有大致的顺序。 在这次实现中，生成的64位ID可以分成5个部分：

0 - 41位时间戳 - 5位数据中心标识 - 5位机器标识 - 12位序列号

5位数据中心标识、5位机器标识这样的分配仅仅是当前实现中分配的，如果业务有其实的需要，可以按其它的分配比例分配，如10位机器标识，不需要数据中心标识。

Java代码实现如下：

/

进制转换工具，最大支持十进制和62进制的转换

1、将十进制的数字转换为指定进制的字符串；

2、将其它进制的数字（字符串形式）转换为十进制的数字

@author xuliugen

@date 2018/04/23

/

public class NumericConvertUtils {

/

在进制表示中的字符集合，0-Z分别用于表示最大为62进制的符号表示

/

private static final char[] digits = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',

'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm',

'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z',

'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M',

'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z'};

/

将十进制的数字转换为指定进制的字符串

@param number 十进制的数字

@param seed 指定的进制

@return 指定进制的字符串

/

public static String toOtherNumberSystem(long number, int seed) {

if (number < 0) {

number = ((long) 2 0x7fffffff) + number + 2;

}

char[] buf = new char[32];

int charPos = 32;

while ((number / seed) > 0) {

buf[--charPos] = digits[(int) (number % seed)];

number /= seed;

}

buf[--charPos] = digits[(int) (number % seed)];

return new String(buf, charPos, (32 - charPos));

}

/

将其它进制的数字（字符串形式）转换为十进制的数字

@param number 其它进制的数字（字符串形式）

@param seed 指定的进制，也就是参数str的原始进制

@return 十进制的数字

/

public static long toDecimalNumber(String number, int seed) {

char[] charBuf = numbertoCharArray();

if (seed == 10) {

return LongparseLong(number);

}

long result = 0, base = 1;

for (int i = charBuflength - 1; i >= 0; i--) {

int index = 0;

for (int j = 0, length = digitslength; j < length; j++) {

//找到对应字符的下标，对应的下标才是具体的数值

if (digits[j] == charBuf[i]) {

index = j;

}

}

result += index base;

base = seed;

}

return result;

}

}

/

Twitter的SnowFlake算法,使用SnowFlake算法生成一个整数，然后转化为62进制变成一个短地址URL

@author beyond

@author xuliugen

@date 2018/04/23

/

public class SnowFlakeShortUrl {

/

起始的时间戳

/

private final static long START_TIMESTAMP = 1480166465631L;

/

每一部分占用的位数

/

private final static long SEQUENCE_BIT = 12; //序列号占用的位数

private final static long MACHINE_BIT = 5; //机器标识占用的位数

private final static long DATA_CENTER_BIT = 5; //数据中心占用的位数

/

每一部分的最大值

/

private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);

private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);

private final static long MAX_DATA_CENTER_NUM = -1L ^ (-1L << DATA_CENTER_BIT);

/

每一部分向左的位移

/

private final static long MACHINE_LEFT = SEQUENCE_BIT;

private final static long DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;

private final static long TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;

private long dataCenterId; //数据中心

private long machineId; //机器标识

private long sequence = 0L; //序列号

private long lastTimeStamp = -1L; //上一次时间戳

/

根据指定的数据中心ID和机器标志ID生成指定的序列号

@param dataCenterId 数据中心ID

@param machineId 机器标志ID

/

public SnowFlake(long dataCenterId, long machineId) {

if (dataCenterId > MAX_DATA_CENTER_NUM || dataCenterId < 0) {

throw new IllegalArgumentException("DtaCenterId can't be greater than MAX_DATA_CENTER_NUM or less than 0！");

}

if (machineId > MAX_MACHINE_NUM || machineId < 0) {

throw new IllegalArgumentException("MachineId can't be greater than MAX_MACHINE_NUM or less than 0！");

}

thisdataCenterId = dataCenterId;

thismachineId = machineId;

}

/

产生下一个ID

@return

/

public synchronized long nextId() {

long currTimeStamp = getNewTimeStamp();

if (currTimeStamp < lastTimeStamp) {

throw new RuntimeException("Clock moved backwards Refusing to generate id");

}

if (currTimeStamp == lastTimeStamp) {

//相同毫秒内，序列号自增

sequence = (sequence + 1) & MAX_SEQUENCE;

//同一毫秒的序列数已经达到最大

if (sequence == 0L) {

currTimeStamp = getNextMill();

}

} else {

//不同毫秒内，序列号置为0

sequence = 0L;

}

lastTimeStamp = currTimeStamp;

return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT //时间戳部分

| dataCenterId << DATA_CENTER_LEFT //数据中心部分

| machineId << MACHINE_LEFT //机器标识部分

| sequence; //序列号部分

}

private long getNextMill() {

long mill = getNewTimeStamp();

while (mill <= lastTimeStamp) {

mill = getNewTimeStamp();

}

return mill;

}

private long getNewTimeStamp() {

return SystemcurrentTimeMillis();

}

public static void main(String[] args) {

SnowFlake snowFlake = new SnowFlake(2, 3);

for (int i = 0; i < (1 << 4); i++) {

//10进制

Long id = snowFlakenextId();

//62进制

String convertedNumStr = NumericConvertUtilstoOtherNumberSystem(id, 62);

//10进制转化为62进制

Systemoutprintln("10进制：" + id + " 62进制:" + convertedNumStr);

//TODO 执行具体的存储操作，可以存放在Redis等中

//62进制转化为10进制

Systemoutprintln("62进制：" + convertedNumStr + " 10进制:" + NumericConvertUtilstoDecimalNumber(convertedNumStr, 62));

Systemoutprintln();

}

}

}

//生成结果：

10进制：185784275776581632 62进制:dITqmhW2

URL 的构成基本如下

举例如下:

拆解如下:

http:// 为协议名,标明了请求需要使用的协议,通常使用的是 HTTP 协议或者安全协议 HTTPS 其他协议还有 mailto: 用户打开邮箱的客户端,和 ftp: 用来做文件的转换, file 用来获取文件, data 获取外部资源等

wwwexamplecom 为域名,标明了需要请求的服务器的地址

:80 是端口号,标明了获取服务器资源的入口

端口号用于区分服务的端口,一台拥有IP地址的服务器可以提供许多服务，比如 Web 服务、 FTP 服务、 SMTP 服务等那么，服务器的资源通过“IP地址+端口号”来区分不同的服务

如果把服务器比作房子,端口号可以看做是通向不同服务的门,

/path/to/myfilehtml 表示服务器上资源的路径,过去这样的路径标记的是服务器上文件的物理路径,但是现在,路径表示的只是一个抽象地址,并不指代任何物理地址

key1=value1&key2=value2 是请求里提供的额外参数这些参数是以键值对的形式,通过 & 符号分隔开来,服务器可以通过这些参数进行相应的个性化处理

#SomewhereInTheDocument 是对资源的部分补充 fragment 可以理解为资源内部的 书签 用来想服务器指明展示的内容所在的 书签 的点例如对于 HTML 文件来说,浏览器会滚动到特定的或者上次浏览过的位置对于音频或者视频资源来说,浏览器又会跳转到对应的时间节点

我们上面所说的都是 绝对路径 ,但是 URL 也有 相对路径 的表现形式

URL 所请求的资源依赖于请求所在的上下文,也就是当前环境,在浏览器的输入框内 URL 没有上下文,所以必须提供 绝对路径

但是当 URL 用于文件中时,例如 HTML 的页面,情况就大有不同了,因为浏览器已经拥有了文件的 URL ,所以可以自动填补文件内使用的 URL 丢失的部分,例如 协议 , 域名 , 端口 等,所以我们可以较为直观的区分 相对路径 和 绝对路径

如果 URL 以 / 开头,浏览器会从根服务器去获取资源,而不是从给定的文件夹中获取

我们用一些例子来直观的理解下

完整的 URL :

隐藏协议

//developermozillaorg/en-US/docs/Learn

浏览器会使用文件主机的相同协议

隐藏域名

浏览器会使用文件主机的相同协议和同样的域名,注意,不能在未隐藏协议的前提下只隐藏域名