마음대로 개발 LIFE

** KOCW에서 이석복 교수님의 네트워크(2015년) 강의를 수강한 내용을 정리한 글입니다.

http://www.kocw.net/home/search/kemView.do?kemId=1169634

Application layer에 대해 알아볼 예정

계층 구조 (- 각각의 대표적인 프로토콜) → 탑 다운 방식으로 살펴볼 예정

Application - HTTP

Transport - TCP / UDP

(이상은 라우터에는 존재하지 않고, 네트워크 엣지에만 존재)

Network - IP

Link - WiFi / LTE / 3G / Ethernet

Physical

HTTP에 대해서 알아보자

Client-server architecture

• Server
  • Always-on host
  • 고정된(Permanet) IP address
• Client
  • Server와 통신
  • 동적 IP를 가지고 있을 것임
• 서로 다른 host(컴퓨터)에 올라와 있는 프로세스(각각 서버, 클라이언트) 사이의 통신을 애기하는 중
• 같은 host에 올라와 있는 프로세스 간 통신은(IPC - Inter-Process Communication) OS에서 처리
• 통신 메시지를 주고 받는 공간을 Socket이라고 함
• 양단을 연결하려면 주소가 특정되어야 함 → IP(컴퓨터 특정) + Port(프로세스에 물린 소켓 특정)의 조합으로 특정
  • IP를 DNS(Domain Name System)에 의해 별도의 주소(이름)로 연결할 수 있음
  • port 입력 안 하면 → 자동으로 80번
  • naver.com:80 해도 연결됨, 8080은 안됨
  • 우리가 알고 있는 모든 웹 서비스들이 80번 포트를 씀 → DNS를 쓰기 때문에, port 넘버는 80번으로 통일하자는 암묵적 합의

App은 Transport 계층에 이런 것을 원한다

• Data integrity : 데이터 무결성
• Timing : 낮은 딜레이 보장
• Throughput : 최소한의 데이터 양 보장
• Security : 보안

하지만 TCP에서 Data integrity를 제공하지만 UDP는 그마저도 안 해주고, 나머지 기능은 제공하지 않는다 → Application layer에서 처리해야 함

App들의 프로토콜 사용 예시

HTTP란?

• HyperText Transfer Protocol
• 웹의 Application layer protocol
• Client / Server model
  • Client : 웹 오브젝트를 요청, 수신, 화면에 표시하는 브라우저
  • Server : Response에 담긴 오브젝트를 요청한 곳에 전달하는 웹 서버
  • 모두 HTTP를 사용
• 쉽게 생각하면, Reqeust를 보내고 Response를 받아오는 프로토콜(규격, 방식)

HTTP는 기저에 TCP 서비스를 사용 → TCP Connection을 생성해야 한다.

• Client는 서버에 TCP Connection을 실행(Socket 생성) (port 80)

→ Server는 Client에서 온 TCP Connection을 수용

→ HTTP 메시지가 브라우저(HTTP Client)와 웹 서버(HTTP Server) 사이에서 교환됨

→ TCP Connection 종료

HTTP는 “stateless(무상태)” 하다

→ Server는 Client의 과거 요청 정보(state)를 가지고 있지 않는다

만약 state를 유지하는 Protocol이라면?

• 과거 기록이 계속 유지되어야 한다
• 만약 Server나 Client가 충돌하면 → view의 상태는 일관성이 없어지고, 반드시 조정되어야 한다.

HTTP Connections

HTTP는 TCP Connection을 non-persistent(비영구적) / persistent(영구적)으로 사용하는지에 따라 분류된다.

• Non-persistent HTTP
  • 1개의 오브젝트를 전송하면 TCP Connection을 바로 닫는다
  • 실제로는 파이프라인과 결합하여, n개의 메서드를 전송하고 Connection을 닫는 방식을 사용함

** KOCW에서 이석복 교수님의 컴퓨터네트워크(2015년) 강의를 수강한 내용을 정리한 글입니다.

http://www.kocw.net/home/search/kemView.do?kemId=1169634

[컴퓨터네트워크

인터넷을 동작시키는 컴퓨터네트워크 프로토폴을 학습한다.

www.kocw.net](http://www.kocw.net/home/search/kemView.do?kemId=1169634)

노드 4개로 시작했던 최초의 인터넷(ARPANET)

현재는 →

네트워크 구조

• 네트워크 엣지(가장자리) : 어플리케이션, 호스트
• 네트워크 코어(중심) : 라우터(아래 그림에서 X 표시된 동그라미) / 네트워크 속 네트워크
• 네트워크 사이를 연결 : 통신 링크

네트워크 엣지

• 엔드 시스템 : 어플리케이션 프로그램 실행 (Web, email)
• 클라이언트 / 서버 모델 (웹 브라우저, 웹 서버, 이메일 클라이언트, 이메일 서버)

TCP(Transmission Control Protocol)

• Connection-oriented(연결 지향)
• 엔드 시스템 간 데이터 전송을 위한 프로토콜
• Relidable(신뢰할 수 있는) / In-order byte-stream(데이터 전송 순서를 유지하는) 데이터 전송
• Flow control : Receiver(수신자)에 맞게 전송
• Congestion control : 과부하 등 감안
• UDP에 비해 신뢰할 수 있다는 장점이 있지만, 비용이 많이 듦

UDP(User Datagram Protocol)

• Connectionless(비연결)
• 엔드 시스템 간 데이터 전송을 위한 프로토콜
• Unreliable data transfer
• No flow control
• No congestion control
• TCP에 비해 속도가 빠름 → 신뢰할 수 없어도 괜찮은 곳에 사용

TCP의 용도 : HTTP(Web), FTP(File transfer), Telnet(Remote login), SMTP(email)

UDP의 용도 : 스트리밍 미디어, 원격 회의, DNS, 전화(Telephony)

프로토콜(Protocol)이란?

쉽게 말해, 대화(통신)의 규칙, 규격

네트워크 코어

상호 연결된 라우터들의 집합(mesh)

어떻게 데이터는 망을 통해 전달될까?

• 써킷 스위칭 : 호출마다 전용(dedicated) 회로 할당 → 전화망
  • 시작부터 끝까지 미리 할당해놓고 시작 (자원 예약)

• 패킷 스위칭 : 불연속적인 덩어리 단위로 망을 통해 데이터를 보낸다 → 인터넷
  • 자원을 예약하지 않음

패킷 스위칭 vs 써킷 스위칭

• Band width(통신망-Link 의 전송 가능 속도) : 1Mb/s 일때
• 유저가 100kb/s를 사용할 때(When active)
• 10%의 시간에 활성(Active)된다면
• 써킷 스위칭 : 10명의 유저 감당 가능
• 패킷 스위칭 : 35명의 유저를 감당해도 활성 유저가 10명 초과할 확률이 0.0004 미만
• 인터넷에서 패킷 스위칭을 사용하는 이유 : 인터넷 사용 시, 특정 시점에만 데이터 송수신하는 경우가 많음
  • 단, 동시 접속을 해야 하는 경우 문제가 생길 수 있음

패킷 딜레이의 원인

1. Processing delay : 패킷을 확인해야 함 (비트 에러, 목적지 등)
2. Queueing delay : Input속도가 Output속도보다 빠르면 → queue에 저장해야 함
3. Transmission delay : 패킷이 모두 통과하는 데에 걸리는 시간
   1. 패킷 길이(bits) / 링크 bandwidth(bps) → s(second) 단위
4. Propagation delay : 전송에 걸리는 시간 → 거리/빛의 속도

패킷 딜레이를 줄여보자

1. Propagation delay → 불가능
2. Processing delay : 라우터 성능 개선
3. Queueing delay : ??
4. Transmission delay : 케이블 성능 개선(Bandwidth 개선)

• 고속도로 예시
  • 톨게이트 하이패스 도입 → Processing delay 개선
  • 차선 늘리기 → Transmission delay 개선
  • 그럼에서 명절에는 막힌다 → Queueing delay는 어쩔 수 없다
    • Transmission 속도가 빨라지면 queue 처리 속도도 빠르지만, 그래도 queue가 쌓여 있다면 처리하는 시간이 걸린다.
    • 대부분의 네트워크 문제는 Queueing delay에서 발생한다.

Queue가 넘치면 → 패킷 유실! (대부분의 loss가 여기서 발생)

TCP는 Relialbe하다며?(신뢰성 있다며) → Queue에서 loss가 발생하면? → 재전송해야함 → 그 방식은?

→ 시작 단계에서 재전송한다

• TCP는 네트워크 엣지에 존재하고, 사이에 있는 코어(라우터)는 판단을 하지 않는다.
• → dumb core