2017. 10. 7. 18:59ㆍ카테고리 없음
# IP주소가 필요한 이유?
Host A와 Host B간의 메세지를 주고 받기 위해서 필요하다.
예를 들면, 친구 kimbregas에게 이메일을 보내고 싶을 때, 이메일 주소를 알아야지 이메일을 보낼 수 있는 것 처럼.
+) IP주소에 맞게 도착했지만, 어떠한 application에다가 message를 줘야할까?
Host A에게 e-mail packet, http packet이 IP주소 192.xxx.xx.xx로 들어왔다고 가정한다면,
Host A는 각각의 packet이 나에게 잘들어왔지만, 어떤 application packet인지 구분이 안간다.
이를 위해서, Port Number가 존재.
HTTP port number는 80
#URL?
http://kimbregas.tistory.com
URL는 http://~~~만 URL이 아니다. file://~~, ftp://~~ 이 또한 URL이다.
브라우저는 URL를 분석하여 어떠한 Protocol로 해야될지 결정한다.
http:// 는 HTTP protocol로 사용하여 웹 서버에 Access하게 된다.
kimbregas.tistory.com는 웹 서버명을 말한다.
http://kimbregas.tistory.com/(index.html)
위 처럼 사실 index.html 보통 설정되어 있는 데, 생략되어 있다. 데이터 출처 경로명을 말해준다.
웹 서버 접속시 서버측에서 설정해둔 파일 경로명으로 가게 된다.
#HTTP(Hypertext Transfer Protocol)
+) Hypertext란 도대체 뭐지....?
-하이퍼텍스트(Hypertext, 문화어: 초본문, 하이퍼본문)는 참조(하이퍼링크)를 통해 독자가 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트이다. by 위키
-네이버에서 우리가 링크를 타고 다른 페이지를 넘어가는 것을 예로 들면 쉽겠다.
+) HTML은 HyperText Markup Language.
Client |
Server |
1. kimbergas.tistory.com:80 (port 80)으로 TCP connection 시작하자고 server에게 보냄. |
|
|
2.이를 받고, Server는 "Accept"메세지를 Client에게 보냄. |
3. TCP Socket으로 HTTP Request msg보냄 |
|
4. HTTP Request에 담긴 하나의 object에 대해서만 response msg보냄. 보냈으면, TCP connection Close | |
5.HTTP response msg 받고 끝. |
위의 표는 기본적인, HTTP connection 상황.
문제점 #1
만약 Client가 원하는 IP주소에 여러가지의 Object가 있었으면,
TCP connection + HTTP 전송. 이 두가지를 계속해야함.
해결책 #1
만약, Server측에 일정시간동안 TCP connection을 지속시키면, 저러한 overhead가 발생할 필요가 없다.
그래서 persistent HTTP가 탄생. 일정한 timeout을 둔다.
------------------------------------------------------------------------------------------------------------------------------------------------------
문제점 #2
HTTP에서 Server는 과거 client request에 대한 정보를 기억하지 못한다.
그렇다면, 쇼핑몰에 접속하면 어떻게 관심상품을 아는걸까?
해결책 #2
Cookie등장.
1.처음 Server에게 HTTP Request msg를 보낼 때, 이에 대한 응답으로 Server는 HTTP Response Header에 'set-cookie: 123213xxx'를 보냄.
이와 동시에, Server back-end database에 이에대한 정보를 저장.
2.그 이후에 Client가 계속해서 HTTP Request msg를 보낸다면, Request Header안에 123213xxx가 같이 보내져서, Server는 Client의 과거 정보들을 알 수 있는 것.
Cookie와 Session의 차이점.
http://bllizz.tistory.com/15 참고.
대략적인 차이점을 말하라고 하면,
Cookie는 정보를 Client측에서 HTTP Request MSG에 달고다니지만,
Session는 Server측에서 정보를 가지고 있다.
보안측면에서 Session이 Cookie보다 우수하다.
하지만, Client마다 발급된 Session ID를 HTTP Reqeust의 헤더에 쿠키정보를 보고 판단하기 때문에
Cookie랑 작동원리가 비슷하다는 것과 Server측에서 mapping정보를 참고해야되는 것 때문에 속도가 느리다.
+)GET vs POST
GET으로 전달되는 정보는 request msg header에 Query String으로 입력되어 전달된다.
POST는 HTTP request msg body에 포함되어 전달된다.
+)HTTP 주요 status code
200 번대 OK
300 번대 Redirection
400 번대 Client Error 400-> Bad Request (요청 구문 잘못됨)
404-> Not Found (요청한 resource가 서버에 없음)
403-> 접근 금지
401-> 권한 없음
500 번대 Server Error
#DNS(Domain Name System)
www.google.com 이것도 사실은 59.18.46.113:80 으로 되어있는, IP주소와 portnumber의 결합이다.
하지만, 우리가 숫자로 된 웹페이지를 기억하는 것보다 이름으로 기억하는 것이 더욱 편리하다.
이 때문에 숫자로 된 IP주소가 Name으로 바뀌게 되는 것이다.
이러한 이름 Domain 주소를 IP Number로 변환시켜주는 프로그램이 필요하는 데, 이를 해주는 역할이 DNS라 부른다.
DNS의 특징으로는
1) Distributed Database -> 많은 Name Server가 계층구조로 되어있다.
www.google.com이면 .com 서버 갓다가 그 다음, google.com 서버로 간다.
2) Application Layer Protocol
3) UDP로 전송된다는 사실
+) DNS application 그 자체가 reliable함. DNS Query에 대한 응답이 안오면, 바로 다시 보냄.
그리고, DNS는 delay를 최소화 시켜야함. TCP Connection 맺을 시간 없음.
또한, DNS 서버에 cache 기능이 있다. 하지만, 오래된 정보가 있을 수 있다. 이 때문에 TTL를 설정하고, 시간이 지나면 data를 삭제한다.
만약 cache에 기록이 안되어있으면, root DNS에게 요청한다.