Kocw에서 제공하는 한양대학교 이석복 교수님의 컴퓨터네트워크 강의를 수강한 후, 정리한 글입니다. (http://www.kocw.net/home/search/kemView.do?kemId=1312397)
교재 : Computer networking : a top-down approach
PPT : https://gaia.cs.umass.edu/kurose_ross/ppt.htm V7.1
우리는 현재에도 웹 브라우저와 같은 애플리케이션 계층과 인터랙션 하고 있다.
애플리케이션은 셀 수 없이 많이 존재하고, 대표적으로 HTTP 기반의 Web이 있다.
Principles of network applications
네트워크 애플리케이션
; 운영체제 위에서 실행되는 프로세스들이 다른 머신에 있는 프로세스와 메시지를 주고 받는 것
Client-server architecture
- 클라이언트; 서버와 통신하는 것으로, 필요할 때만 액션을 취하는 것
- 서버; 24시간 대기를 하며, 클라이언트의 요청을 받는다.
-
예 : www.naver.com
www.naver.com도 고정된 주소라고 볼 수 있다.
우리가 www.naver.com을 치면 웹 브라우저가 DNS를 통해 도메인에 해당되는 IP 주소를 찾아와서 연결을 해준다. 이때 서버는 이 IP주소가 고정되어 있는 것이다. 이때 포트 번호는 고정 시켜 두는 것이 일반적이다. (HTTP면 80)
만약, HTTP를 사용하는데 80번 포트를 열어두지 않고 777번 포트를 열어두면 ip:port 형식으로 명시 후 넘겨주어야 한다.
- 서버는 고정된 주소를 가져야 한다.
프로세스
; 프로그램을 OS 위에서 실행시킨 것
프로세스 간 메시지 주고받기를 위해서는 프로세스들 간의 통신 파이프가 제공되어야 한다.
많은 프로세스들 중에 특정한 프로세스에 정확히 보내기 위해서는 소켓 인터페이스 주소를 잘 알아야 한다. 이때 IP주소로 프로세스가 동작하고 있는 머신을 지칭하고, 머신 속에 있는 수많은 프로세스들 중에서 대상이 되는 프로세스를 찾기 위해 포트 번호를 사용한다.
애플리케이션이 필요로 하는 전송 서비스
(1) 데이터 무결성
(2) 낮은 지연
(3) 효과적인 처리량
(4) 보안
Web and HTTP
HTTP(Hypertext transfer protocol)
; 이미지 혹은 다른 오브젝트에 대한 링크가 있는 텍스트를 전송하는 프로토콜
request와 response로 이루어져 있다. 이 중 우리가 보는 것은 response에 대한 결과물이다.
uses TCP
HTTP는 TCP를 기반으로 동작하기 때문에 HTTP 메시지들은 중간에 유실되지 않고 서버와 신뢰성 있게 통신 가능하다. TCP를 사용하면 UDP 사용에 비해 비용이 더 들고, 서버와 클라이언트 사이에 TCP Connection이 맺어진다.
HTTP is stateless
서버는 request와 response 이후에는 어떠한 것도 기억하지 않는다.
즉, 클라이언트가 요청한 것에 대해서 기록을 남기지 않는다.
HTTP가 TCP를 사용하는 2가지 방식
Non-persistent HTTP
클라이언트가 서버에게 10개의 인덱스를 가지고 있는 www.someSchool.edu를 요청하려고 한다.
cf) 10개의 인덱스 : 이미지가 10개가 있다는 것이 아닌, 10개의 이미지를 링크하는 주소가 10개 있다는 것
Non-persistent HTTP 방식에서는 이미지 10개를 요청하는 작업을 이미지 1개당 1번으로 총 10번 수행한다.
initiate TCP : 사전에 연결하기 위해 보내는 것으로, 이 과정에 소요되는 시간을 2RTT 정도로 본다.
RTT : 메시지 보내고 오는 시간
time to transmit : 실제 파일이 실려서 오는 부분이기 때문에, 이 요청에 대한 인스턴스 자체는 크다.
Persistent HTTP
; 한 번 연결이 되면 계속 사용할 수 있음
end-to-end delay를 구하는 예를 통해서 살펴보자.
클라이언트와 서버가 있다.
- Control Messages(ex. TCP handshake, HTTP request) = K bit long
- Base HTML object = L bits
- N reference objects, each L bit long
- Link bandwidth = R bps
- Propagation delay = d seconds
(1) TCP Connection을 위한 K 비트 메시지가 전송됨
(2) 1번에서 보낸 시간을 0초라고 하면, 서버에 도착한 시간은 K(메시지크기)/bandwidth+delay가 됨
cf) delay : 제일 마지막에 있는 비트가 도착할 때까지 걸리는 시간
(3) 보내는 시간은 K/R+d가 소요됨
(4) HTTP Request를 보낼 수 있음
(5) HTTP Request 역시 보내는데 K/R+d만큼의 시간이 걸림
(6) Basic HTML의 크기가 L임
(7) Basic HTML을 기준으로 L/R+d만큼의 시간이 걸림
이때 n개의 오브젝트를 가져와야 하는데 persistent이기 때문에 (4)-(7)을 10번 반복하면 된다.
이를 바탕으로 공식을 내리면 n*k/r+d가 된다.
HTTP request Message
도메인을 입력했을 때 HTTP request를 발생시켜서 소켓으로 보내면 request message가 생성된다.
위의 메시지에서 가장 중요한 것은 어떤 게 필요한 지를 나타내는 첫 번째 줄이다.
나머지는 부가 정보라고 보면 된다.
HTTP response meesage
서버가 클라이언트가 요청한 파일을 보내면서 보내는 것이다.
Cookies
HTTP의 stateless를 보완하기 위해서 나온 것이 쿠키이다.
우리가 아마존 서버에 처음으로 request를 하면, 쿠키 파일이 생성된다.
그 이후부터는 접속할 때마다 이전에 생성된 쿠키 파일을 이용하여 사용자를 인식하게 된다.
이 쿠키에 대한 값은 데이터베이스에 적힌다.
아마존에서는 이 쿠키들을 가지고 사용자가 이전에 구매한 책과 유사한 책을 추천하곤 한다.
Web Cache
웹 캐시는 Proxy를 거친다.
웹 캐시를 사용할 때 장점
- 빠르다. → 클라이언트가 행복하다.
- 서버도 행복하다. → 리퀘스트를 로컬에서 다 처리해주니까
- 네트워크 운영자도 행복하다. → 인터넷 외부로 나갔다 들어오는 트래픽이 감소하기 때문에, 이용료가 줄어든다.
웹 캐시를 사용할 때 단점
- 보안에 대한 이슈
- 캐시가 가지고 있는 것과 서버가 가지고 있는 것에 대한 정보 차이가 존재(업데이트가 반영이 안 되었을 경우, 일관성에 대한 문제 발생)
Caching Example
Assumptions
- 한양대학교 네트워크 안에 컴퓨터가 있다. → 1Gbps LAN
- 한양대학교에서 외부로 나가는 네트워크 대역폭은 15,4Mbps → 폭이 좀 더 좁다.
- 브라우저들이 초당 15번 리퀘스트
- 각 오브젝트의 사이즈가 1 메가바이트이기 때문에 초당 브라우저로 들어오는 트래픽은 15 Mbps
- 라우터에서 서버로 갔다가 서버로 돌아오는 시간은 2초
Consequences
내부의 사용률이 15퍼이고, 딜레이는 없다.
문제는 외부랑 연결되는 것이다.
도로에 비유를 들어 생각해보면, 이 경우는 100차선 도로에서 15차선이 사용되고 15.4로 15차선이 가득 차 있는 상태이다.
이런 상태에서는 link 사용률이 80%를 넘으면서 지연이 발생하게 된다.
평균이 15.4라는 건 15.4보다 큰 값이 존재한다는 의미인데 큰 값이 들어오면 막히게 되는 것이다.
그럼 최종적으로 사용자가 체감하는 딜레이를 계산해보자.
- 외부에서 걸리는 시간 = 2초
- 내부에서 걸리는 시간 = 몇 밀리 세컨드 → 엄청 작음
- 내부-외부 시간 = 몇 분?
이렇게 되면 2 sec + minutes + usecs가 최종 딜레이 시간이 된다.
이 문제를 해결하기 위해서 케이블 확장 공사를 해서 10배를 늘렸다고 생각해보자.
이게 가장 직관적인 해결책이다.
이렇게 하면 utilization이 10분의 1로 떨어진다.
154차선에서 9.9만 이동하게 되니까 수분 걸리던 access delay가 msecs가 되면서 엄청나게 빠르게 접근할 수 있게 된다.
근데 이때의 문제는 비용이 엄청나게 든다는 것이다. 이때 사용하는 것이 웹 프록시이다.
요청하는 파일들의 40퍼센트를 local web cache가 가지고 있다고 생각하자.
그럴 경우에 외부에서 처리하는 것은 60퍼가 된다.
외부에서 처리하는 게 60퍼로 줄어들면서, 총 소요 시간은 약 1.2초 정도가 된다.
즉, 케이블 확장 공사를 했을 때보다(2.x초) 더 좋은 효과를 낼 수 있는 것이다.
Condition GET
일관성 문제를 해결하기 위해서는 Condition GET을 사용한다.
파일을 요청할 때 If-modified-since: <date> 를 함께 요청하면서 파일이 이 시간 이후로 수정이 되었는지 비교를 한다. 수정이 안 되었을 경우에는 첫 줄에 304 not modified를 전송하고, 수정이 되어 있는 상태면 파일을 담아서 보낸다.
DNS
DNS는 전화번호부라고 생각하자.
우리가 www.google.com을 입력했을 때 www.google.com에 해당되는 IP주소를 찾아서 매핑해주는 것이 DNS이다.
DNS 서버를 한 대만 사용할 때 문제점
- 검색시간이 어마어마하게 걸린다.
- 사람이 몰려서 서비스가 느려진다.
- 서버가 다운될 경우, 웹 브라우징을 할 수 없다.
⇒ 그렇기 때문에 검색 속도가 빠르고 관리가 용이하도록 분산과 계층화를 시켜야 한다.
TLD, authoritative servers
top-level domain(TLD) server
; .com, .org, .net 같은 도메인을 담고 있는 서버
authoritative DNS servers
; 네트워크를 운영하는 기관에서 보유하고 있는 도메인의 경우, 기관에서 매핑에 대한 수행을 하기 위해 운영하는 DNS 서버(ex. hanyang.edu라는 도메인에 속한 사이트들)
Local DNS name server
; 내부에서 요청되는 DNS 쿼리들에 대한 결과를 캐싱하고 있는 곳(호스트와 아이피를 매칭한 결과를 저장)
웬만해서는 여기서 다 cache hit이 발생한다.
DNS name resolution example
위의 그림은 hostname을 가지고 ip주소를 알아오는 과정을 그린 것이다.
여기서는 poly.edu 학교가 gaia.cs.umass.edu 학교에 메시지를 보내려고 하는 것이다.
(1) 호스트 IP를 알아내기 위해서 local DNS server에 물어봄
(2) local DNS server에 없을 경우 root DNS server에 가서 호스트 IP를 물어봄
(3) root는 호스트 IP를 알 수도 있는 TLD DNS server 주소를 알려줌
(4) TLD DNS Server 주소에 호스트 IP를 물어봄
(5) TLD DNS Server는 호스트 IP를 알고 있는 authoritative DNS server의 주소를 알려줌
(6) authoritative DNS server에 호스트 IP를 물어봄
(7) authoritative DNS server는 호스트 IP를 알려줌
(8) local DNS server는 authoritative DNS server로부터 받은 호스트 IP를 알려줌
DNS: caching, updating records
; 일관성 문제의 대응책으로 TTL이라는 필드를 사용한다.
이 TTL이 지나면 레코드는 expire된다.
DNS records
type=A일 경우,
; name = hostname, value = IP
type=NS일 경우,
; name = domain, value = 호스트 네임을 관리하는 서버의 도메인
NS와 A는 한 쌍으로 다닌다.
hanyang.edu라는 도메인을 담당하는 네임서버의 이름은 dns.hanyang.edu(NS)이고, 이 dns.hanyang.edu의 IP는 5.5.5.5(A)다.
즉, NS를 통해 서버의 이름을, A를 통해 서버의 IP를 알게 되는 것이다.
우리가 상대의 아이피를 알아올 때 A와 NS가 같이 오면 아직 대상 서버의 IP를 알아내지 못한 것이기 때문에 계속 물어보아야 하고,(DNS name resolution example의 3, 5번) A만 오면 대상 서버의 IP를 알아낸 것이다.(DNS name resolution example의 7번)
type 중 CNAME은 별칭이고 MX는 mailserver이다.
cf) DNS는 UDP 기반이다.
→ 크기가 작아서 유실될 확률이 낮기 때문에 빠른 UDP를 사용한다.
electronic mail
electronic mail
이메일은 전통적으로 4가지 컴포넌트로 이루어져 있다.
- user agents : outlook, mail checking app
- mail servers : gmail, naver mail, daum mail
- simple mail transfer protocol : SMTP
Scenario : Alice sends message to Bob
앨리스가 gmail, 밥이 naver, 3번의 메일 서버가 지메일 서버, 5번의 메일 서버가 네이버 서버라고 하자.
(1) 앨리스가 메일을 전송
(2) 앨리스의 이메일 계정이 있는 메일 서버로 메일을 보내짐
(3), (4) 지메일 메일 서버는 네이버 메일 서버에게 SMTP를 사용해서 메일을 보냄
(5) 네이버 메일 서버는 메일을 밥의 계정에 보관함
(6) 밥은 자신의 계정이 담긴 메일 서버에 접속하면 앨리스가 보낸 메일을 가져갈 수 있음
Uploaded by Notion2Tistory v1.1.0