http://blog.naver.com/PostView.nhn?blogId=tttnnn1234&logNo=110091727476 에서 참조

URI와 URL의 차이

Uniform Resource Identifier (URI) consists of a string of characters used to identify or name a resource on the Internet
http://en.wikipedia.org/wiki/URI

URI는 인터넷 상의 자원을 식별하기 위한 문자열의 구성쯤으로 해석 될 수 있겠다.

http://en.wikipedia.org/wiki/URL
URI의 한 형태인 URL은 인터넷 상의 자원 위치를 나타낸다.

URL는 URI의 한 형태로, 바꿔 말하면 URI는 URL을 포함 하는 개념이다.
(URI > URL)

인터넷 상의 자원의 위치와 식별자.
언듯 보면 같은 것을 의미하는 듯 하다.
하지만 ‘자원의 위치’라는 것은 결국은 ‘하나의 파일 위치’를 나타내는 것임을 명심하자.

http://img0.gmodules.com/ig/images/korea/logo.gif
이와 같은 형식은 logo.gif라는 인터넷상의 자원 위치를 의미 한다.
이는 URI이면서도 URL라고 말할 수 있다.

다음은 어떠한가.
http://endic.naver.com/endic.nhn?docid=1232950
http://endic.naver.com/란 서버에 위치한 endic.nhn파일은 query string인 docid의 값에 따라 여러가지 결과를 나타낸다.

여기서 URL은 endic.nhn의 위치를 표기한 http://endic.naver.com/endic.nhn 까지이다.
내가 원하는 정보에 도달 하기위해서는 ?docid=1232950라는 식별자(Identifier)가 필요한 것이다.

결국 위의 http://endic.naver.com/endic.nhn?docid=1232950주소는 URI이긴 하지만 URL은 아니다

[출처] URI 와 URL의 차이|작성자 너부리

URI 가 더 큰 개념이라고 할 수 있죠..
URI는 Uniform Resource Identifier 의 약자로
URL(Uniform Resource Locator)와 URN(Uniform Resource Name) 을 포함합니다.

아래의 자세한 내용은 http://www.xmlgo.net/open_xml/namespace/uri-url-urn.html 에서 발췌한 내용입니다. 참고하세요..

URLs

URL은 실제의 네트웍 경로를 가리키며, 네트웍 상의 리소스 접근시에 사용된다 URL의 첫 번째 부분은 다음과 같은 프로토콜을 명시하는데, 대부분의 경우 http이며, 가끔은 ftp 혹은 mailto이며, 드물게 gopher, news, telnet, file 등을 사용합니다. 이와 같은 URL 프로토콜 부분을 scheme이라고 한다. Scheme 뒤에는 콜론(:)이 따라오며 그 뒤에 식별된 자원의 경로가 나타난다. 다음의 예는 여러 분들이 매우 익숙할 것이다.

    http://www.xmlgo.net/document/editor/editor.html

이 URL은 www.xmlgo.net 이라는 이름의 인터넷 상에 있는 서버로부터 /document/editor/editor.html 이라는 파일을 검색하기 위하여 사용될 수 있는 경로(PATH)를 나타낸다. 파일 editor.html 은 /document/editor 이라는 디렉토리에 있으며, HTTP 프로토콜에 의하여 검색되야함을 명시한다. 또 다른 예로써 다음과 같은 전자메일 계정을 가리키는 URL도 있다.

    mailto:someone@sungshin.ac.kr

계속해서 다양한 프로토콜에 따른 예를 들어 본다면 ,

  • file -시스템내의 파일 이름 ( file:///C:windowsxmltest.xml )

  • ftp – ( ftp://ftp.is.co.za/rfc/rfc2141.txt )

  • news – 유즈넷 뉴스 그룹 ( news:comp.xml.xsl )

  • telnet – telnet://www.xmlgo.net

물론 URL을 통하여 검색될 수 있는 자원에는 제한이 있다. 컴퓨터로부터 검색가능한 형태의 자원만 검색할 수 있다. 실제의 예를 든다면 , RDF (URI상의,리소스에 관해 기술하는 규칙) : http://www.w3.org/TR/REC-rdf-syntax# SVG (2차원 그래픽,벡터형태의 그래픽, 이미지, 텍스트를 포함,을 표현하는 XML 용어집): http://www.w3c.org/XSL/Format/1.0 등이 네임스페이스로 사용된다.

URNs

URN은 자원에 대하여 영속적 (persistent)이고 유일하다. 위치에 독립적인 이름을 제공하기 위하여 존재한다. 이것은 RFC 2141 (http://www.ietf.org/rfc/rfc2141.txt) 에 정의되어 있다.

iURN은 문자열 “urn” 혹은 “URN”, NID (Namespace Identifier), 그리고 NSS (Namespace Specific String)로 구성되어 있으며 각 구성 엘리먼트간에 콜론(:)을 위치시킨다. NID는 URN의 형태를 나타내는데, 예를 들어 차후 XMLgo.net에서 ebXML문서의 형태로 각 회사의 정보를 기억해 두는 저장소를 URN으로 가리키고 , NSS 는 유일하고 영속적이여야 하며, 여기서는 registry1이라고 칭하였다.

    urn:xmlgo:registry1

좀더 현실적인 예를 들어 본다면

한국인을 위한 URN을 만들기 위하여 한국-시민 이라고 선언할 수 있다. NSS 로는 유일한 번호, 주민등록 번호를 표현하도록 한다면 000000-0000000 이 될 것이다.

    urn:한국-시민:000000-0000000

지금까지의 내용을 종합해 보면, Namespace를 지정할 때 URI 로 지정한다. URI로는 현재 널리 사용하는 웹주소, URL 방식과 URN 방식이 포함 되어 있다. 일반적으로 URL을 많이 사용하나 URN도 널리 사용 될 것이다. URL에서는 도메인 주소와 거기에 위치한 물리적인 경로가 자원을 찾기 위한 중요한 정보가 되지만, URN은 자원에 부여된 고유한 이름으로 그 자원의 위치와는 무관하게 부여된 이름이다.

이를 구체적으로 예를 들면 , 인천 광역시 남구 용현동에 인하대학교가 있지만, 인하대학교는 새로운 부지로 이사를 갈 수도 있을 것이다. 인하대학교가 어디에 있는지는 URL(주소)로 표현 할 수 있지만, 인하대학교가 다른 곳으로 가더라도 URN을 가지고 그 리소스(인하대학교)을 식별할 수 있다. 이사를 가고 나서 ‘인천광역시 남구 용현동의 인하대학교’ 라는 기존의 주소를 가지고는 인하대학교를 찾을 수 없다. 하지만 인하대학교란 고유한 이름은 변함이 없을 것이다

http://brown.ezphp.net/39 에서 참조

HTML 밖에 모르는 웹 브라우저 ?

웹 브라우저는 HTML밖에 모릅니다. HTML이 브라우저가 쓰는 언어라는 것이지요. (자바스크립트와 같은 약간의 외국어도 합니다.^^;;) 그래서 우리가 홈페이지를 만들려면 모든 문서를 HTML로 작성해야만 합니다.

HTML을 울려 버린 CGI의 등장

인터넷 초창기에는 대부분의 홈페이지가 모두 HTML(SGML)로 만들어져 있었습니다. (선택의 여지가 없었죠)
HTML로 홈페이지를 만들어 보신 분은 아시겠지만 HTML은 일방향적이고 수정하기 전에는 절대 변하지 않는 특성을 가지고 있습니다. 이러한 단점 때문에 사람들은 HTML 말고 다른 무언가가 필요함을 느꼈습니다. 그래서 생겨난 것이 바로 CGI (Common Gateway Interface)입니다.

CGI의 구조

CGI는 위와 같은 구조를 가지는데.. ( HTML은 1과 4의 과정만 있음 ) 보시는 바와 같이 HTML 보다 한단계 더 처리를 함으로써 계산과 처리 기능이 추가되었습니다.  이로 인해 우리는 정적인 웹 페이지에서 변화가 자유롭고 방문자와 홈페이지간에
서로 상호작용이 가능한 웹 페이지를 만들 수 있게 된 것입니다. 그러나 여기서 주의해야 할 점은 3번에서 보듯이 CGI로 처리된 값은 HTML로 전송됩니다. 웹 브라우저가 HTML밖에 모르니 HTML로 결과를 보여줘야 하는 것입니다. 그러니 PHP를 하려면 당연히 HTML을 알고 있어야겠죠?

그러면 CGI와 PHP는 어떤 관계인가?

PHP는 약간 다르긴 하지만 일종의 CGI라고 볼 수 있습니다. 그래서 PHP도 저 위의 그림과 비슷한 구조를 가집니다.

참고. (중급)
CGI는 일반적으로 웹서버로 요청이 들어오면 CGI 프로그램을 실행하여 하나의 프로세스를 생성하고 그 처리 결과를 웹서버로 전송한 후 프로세스가 종료되는 형식입니다. 100개의 요청이 들어오면 CGI 프로세스가 100개가 생성이 됩니다.

PHP는 CGI와 달리 아파치 웹서버에 모듈로 장착되어 있습니다. 따라서 매회 실행시마다 프로세스가 생성되는 CGI와 달리 하나의 프로세스에 여러개의 쓰레드를 생성하여 처리가 가능합니다.

프로세스, 쓰레드?? 뭐가다르냐구요? 프로세스는 각각 별도로 시스템 자원을 소비합니다. 1개의 프로세스가 메모리 1메가바이트를 소비한다면 100개의 경우 100메가 바이트의 메모리를 소비하게 됩니다. 그러나 쓰레드는 쓰레드간에 시스템자원의 공유가 가능하므로 100개라고해서 100메가 바이트를 소비하는 것이 아니라 그보다 훨씬 적은양의 메모리를 소비하게 됩니다.
그래서 프로세스방식인 CGI 보다 쓰레드방식인 PHP가 성능이 우수합니다.

http://blog.daum.net/haha25/5387375 에서 참조

DDL(데이터 정의어)Data Definition정의 Language
▪ SCHEMA, DOMAIN, TABLE, VIEW, INDEX를 정의하거나 변경 또는 삭제할 때 사용하는
언어
▪ 데이터베이스 관리자나 데이터베이스 설계자가 사용함
▪ 데이터 정의어(D이)의 3가지 유형

 명령어 기능
CREATE  – Schema, Domain, Table, View, Index를 정의함
ALTER    –  Table에 대한 정의를 변경하는데 사용함
DROP     –  Schema, Domain, Table, View, Index를 삭제함

DML(데이터 조작어)Data Manipulation조작, 속임수  Language
▪ 데이터베이스 사용자가 응용 프로그램이나 질의어를 통하여 저장된 데이터를 실질적으로
처리하는데 사용하는 언어
▪ 데이터베이스 사용자와 데이터베이스 관리시스템간의 인터페이스 제공
▪ 데이터조작어(DML)의 4가지 유형

 명령어 기능
SELECT       테이블에서 조건에 맞는 튜플을 검색함
INSERT        테이블에서 새로운 튜플을 삽입함
DELETE       테이블에서 조건에 맞는 튜플을 삭제함
UPDATE       테이블의 조건에 맞는 튜플의 내용을 변경함

 DCL(데이터 제어어)
▪ 데이터의 보안, 무결성, 데이터 회복, 병행 수행 제어 등을 정의 하는데 사용하는 언어
▪ 데이터베이스 관리자가 데이터 관리를 목적으로 사용함
▪ 데이터 제어어(DCL)의 종류

 명령어 기능
COMMIT        데이터베이스 조작 작업이 정상적으로 완료되었음을 관리자에게 알려줌
ROLLBACK     데이터베이스 조작 작업이 비정상적으로 종료되었을 때 원래의 상태로 복구함
GRANT           데이터베이스 사용자에게 사용권한을 부여함
REVOKE        데이터베이스 사용자의 사용권한을 취소함

XML 과 HTML 의 차이

http://misako.co.kr/articles/HttpVSHttps.aspx

에서 참조

 

HTTP 대 HTTPS : 뭐가 다른가?

신정훈

  웹 브라우저의 주소창을 자세히 보면 http://나 https://로 시작한다. 사실 http://는 하도 흔해서 생략하고 주소를 쳐도, 웹 브라우저가 알아서 http://를 넣어 준다. 어제 인터넷에서 GMail 옵션 중에 항상 https를 사용하도록 하는 옵션이 있다고 그걸 쓰라는 글을 보았다. 거기 달린 답글 중에 두 개가 뭐가 다른지 모르겠다고 하는 글이 있었다. 그럼 이 두 개의 차이는 뭘까? 이름도 비슷한데. html하고 http는 다른 건가? 나도 예전에는 헛갈렸었다. 그럼 이들에 대해서 내가 아는 범위 내에서 간단히 설명을 하겠다.

HTML이란

   우리가 보는 웹 페이지의 대부분은 확장자가 html이다. htm인 것도 있는데, 그것은 예전 도스 기준으로 확장자가 3자밖에 되지 않기 때문에 어쩔 수 없이 끝을 자른 것으로 요즘은 잘 없다. 기타 php, aspx, jsp 등도 있다. 이들은 각각 웹 서버의 처리 엔진에 따른 결과물인데, 사실 확장자는 중요한 게 아니다. 어차피 확장자가 php,aspx,jsp인 것도 다들 html이다. 웹 브라우저는 확장자를 보고 이게 html인 줄 아는 게 아니라, 헤더에 있는 타입을 보고 아는 것이다. 우리가 보기에 확장자가 php라도, 헤더에는 txt/html로 타입이 규정되어 있고, 웹 브라우저는 그래서 이게 html인 줄 안다. 웹 페이지는 메모장으로 소스 보기를 하면 보이듯이 <tag>이런 태그로 둘러싸인 텍스트 문서이다. 그림 파일이나 다른 요소는 따로 표시되어 있지 페이지 속에 들어가지 않는다.

HTTP란

  Http는 이런 HTML 같은 문서를 웹 브라우저가 웹 서버에 요청하는 프로토콜이다. 프로토콜이라는 것은 일종의 대화 규칙이다. 우리가 폰뱅킹할 때를 보면 지정된 코드를 누르면 정해진 응답이 온다. 그런 것이다. 이게 없다면 웹 서버는 웹 브라우저가 무슨 페이지를 달라고 하는 건지도 모를 것이고 웹 브라우저도 웹 서버가 무슨 페이지를 보내는 건지 알 수가 없다. Http도 그냥 텍스트 교환일 뿐이다. 복잡한 바이너리 데이터가 아니라 그냥 텍스트 메시지를 주고 받는다. 물론 그 텍스트 메시지 안에 HTML 페이지도 들어 있다. 텍스트이기 때문에 만약 내가 있는 네트워크 안에서 누가 그 신호를 가로채어 본다면 내용이 그대로 보이게 된다. 만약 내가 메일을 읽고 있는데 누가 그 신호를 가로챈다면 메일 내용을 읽을 수 있을 것이다.

HTTPS란

  Https는 http하고 거의 같지만 모든 통신 내용을 암호화하는 것이 다르다. 사실 s가 secure socket, 즉 안전한 통신망을 뜻한다. 우리는 파일에 암호를 많이 걸어 봤다. 어떤 키를 설정해서 걸면 나중에 풀 때에도 그걸 입력해 푸는 것이다. 키라는 것은 암호화를 푸는 암호 즉 패스워드같은 것이다. 웹 서버가 키 하나를 정해서 페이지를 암호화해서 사용자의 웹 브라우저로 보내고 웹 브라우저는 그 키를 이용해서 페이지를 복원한다… 이러면 좋겠지만 이렇게 간단하지 않다. 웹 서버는 하나이지만 사용자는 불특정 다수이다. 그런데 키를 사용자들에게 줘 버리면 아무나 암호화를 풀 수 있게 된다. 영희에게 갈 페이지를 철수도 풀어서 볼 수 있게 되는데, 이러면 암호화의 효과가 없다.

 즉, 페이지 암호화 키가 그 페이지를 보는 특정 사용자에게만 알려져야 한다. 어떻게 이렇게 할 수 있을까? 이것이 바로 https 프로토콜이 하는 것이다. 위에서 말한 암호화 방식을 사용하되, 그 키를 다시 공개 키로 암호화하고 인증하는 것이다. 공개 키는 쉽게 말해서 데이터를 암호화하는데 키가 두 개 필요하다는 것이다. 암호화를 푸는 데에는 그 두 개 중 하나의 키만 있으면 된다. (수학적으로 로그 지수를 찾는 것이 어려운 문제에 기초하고 있다. 이렇게 자세한 것까지 알고 싶은 사람은 없겠지만.) 이게 무슨 뜻일까? 옥션 사이트에서는 A,B라는 키를 가지고 있다. 그리고 이 B라는 키만 사용자들에게 알려 준다. 그리고 옥션 사이트에 웹 브라우저가 연결을 시도할 때, 파일 암호화 키를 이 A,B 키로 암호화해서 보내 준다. 그러면 사용자들은 B라는 키로 데이터를 풀어 볼 수 있다. A는 옥션 관리자 말고는 아무도 모르기 때문에, B만 알아서는 옥션과 똑같이 암호화를 할 수 없다. 즉 사용자는 B로 풀어 봐서 풀어지면 이 데이터는 A키를 아는 옥션 관리자가 암호화한 것이라는 걸 알 수 있는 것이다. http 프로토콜의 경우 중간에서 네트워크 데이터를 가로채어서 마치 자기가 옥션 사이트인 것처럼 해서 가짜 페이지를 보낼 수도 있다. 하지만 https의 경우에는 A키를 모르기 때문에 중간에서 누가 그렇게 할 수가 없다. 이렇게 해서 반대편이 옥션이라는 것을 우리는 믿을 수 있다.

   이렇게 믿을 수 있으면 IE같은 브라우저에서는 주소 창의 색을 다르게 해서 안전하다고 알려 준다. 이렇게 해서 웹 서버와 사용자가 교환한 키로 전체 이후로는 HTML을 암호화해서 교환하는 것이다. 이렇게 되면 중간에서 웹 페이지를 누가 가로채어도 내용을 전혀 읽을 수 없다. 사실 시간이 주어진다면 암호화를 풀 수도 있다. 예를 들어 1024비트 암호화를 사용한다면 암호 키가 1024비트, 즉 2의 1024승이라는 것이다. 암호를 계산해서 푸는 방법은 없다 (있다면 그런 암호화는 폐기된다). 키를 모르고 암호화를 푼다는 것은 모든 키를 하나씩 다 대입해서 풀릴 때까지 해 보는 것이다. 그러면 위의 경우 평균적으로 2의 512승 번을 해 봐야 한다. 2의 512승과 2 x 512는 차원이 다르다. 2의 20승만 해도 백 만이 넘는다. 아무리 빠른 컴퓨터로 대입해도 아마 몇 천 년은 해야 할 것이다. 그래서 안전한 것이다.

결론

  그러면 https가 안전한데 다 https를 쓰지 http를 뭐하러 쓰느냐고 할 것이다. https 암호화를 하려면 웹 서버에 부하가 생기고, 위에서 말한 B가 그 서버의 인증서가 되는데, 이것은 Verisign 같은 업체에서 비싼 돈을 주고 사야하므로, 특히 우리 나라 웹 사이트들은 잘 쓰지 않는다. 하지만 외국 금융 사이트에서는 https는 필수이다. 또 http는 비연결형으로 웹 페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있지만 https의 경우에는 소켓 (데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷 연결이 끊기면 소켓도 끊어져서 다시 https 인증을 해야 한다. 그래서 시간이 또 걸린다.

   그래서 아무나 봐도 상관 없는 페이지는 http로, 남에게 보이면 안 되는 금융 정보나 메일 등 중요한 것은 https로 하는 것이다. GMail은 https를 지원한다. 다른 메일을 사용하는 사람은 보안 문제를 좀 더 생각해 보자.