Section 01. 전송 계층

01. 전송 계층의 이해

전송 계층(Transport layer)은 네트워크 계층의 오류를 보정해주어 인터넷에서의 오류 없는 데이터 전송을 위한 계층이다.

• TCP: 여러 프로그램들이 데이터를 보낼 수 있는 인터페이스를 만들어 준다.

  • 전송계층의 대표적인 프로토콜

  • 프로그램들은 TCP를 통해 인터넷을 이용할 수 있는 것

  • 이때, 인터페이스는 TSAP(Transport Service Access Point)

    

• TPDU(Transport Protocol Data Unit): 전송 계층 데이터의 단위

  • 응용 프로그램이 전달할 데이터에 전송 계층 헤더를 붙여 네트워크 계층으로 내려보낸다.
    

• 전송 계층은 목적지에 도착한 데이터의 순서가 뒤바뀌거나 사라진 것은 없는지 확인한다.

  • 일련번호와 ACK 사용

• 혼잡 제어(congestion control)

  • 슬라이딩 윈도우 프로토콜 사용 (stop and wait, go back N, selective repeat)

• IP는 목적지까지 데이터를 전송만 하기 때문에 연결이라는 개념이 없다.

  → 전송 계층은 응용 프로그램의 연결을 설정하고 해제하는 작업 또한 지원한다.
  

02. 포트와 소켓

- 서버와 데몬

웹 시스템은 클라이언트-서버 구조이다. 이때 클라이언트는 서비스를 요청하는 컴퓨터, 서버는 클라이언트의 응답을 받아 원하는 서비스를 제공한다.

• 웹 브라우저는 클라이언트 소프트웨어를 대표하는 단어. (익스플로러, 크롬, 파이어 폭스)

웹 브라우저는 서버 컴퓨터에 접속하여 웹 페이지를 요청한다. → HTTP(Hyper Text Transfer Protocol) 사용. 하이퍼 텍스트(웹 페이지)를 전송하라는 프로토콜.

서버는 요청을 받으면 HTML(Hyper Text Markup Language)을 사용하여 만들어진 웹 페이지를 클라이언트에게 전송하고, 웹 브라우저가 웹 페이지를 화면에 보여준다.

이때 클라이언트 소프트웨어는 사용자가 필요할 때 사용하고, 필요 없으면 종료한다. 반면 서버 소프트웨어는 클라이언트가 언제 서비스를 요청할지 모르기 때문에 항상 대기 상태로 기다려야 한다.

→ 데몬(daemon): 죽지 않고 살아서 서비스를 계속하는 프로그램

따라서 서버는 HTTP(웹 서비스)를 받아 줄 데몬이 설치되어 있어야 하고, 이때 웹 데몬을 HTTPD(HTTP Daemon) 이라고 한다.

• 보통 프로토콜 이름 뒤에 D를 붙인다.
• HTTPD의 제품은 아파치, 톰캣, IIS 등이 존재

⇒ 서버는 데몬이 설치된 컴퓨터 (→ HTTPD가 설치된 컴퓨터는 웹 서버)

⇒ 웹 서버를 구축한다 = HTTPD(웹 데몬)을 컴퓨터에 설치한다.

인터넷을 통해 파일을 주고받는 경우도 파일 전송에 사용되는 FTP(File Transfer Protocol)에 응답하는 파일 서버를 구축하기 위해 FTPD를 설치해야 한다.

이메일 또한 SMTP(Simple Mail Transfer Protocol) 라는 프로토콜이 존재하는데, 어떤 컴퓨터를 이메일 서버로 만들고 싶다면 SMTPD 를 설치해야 한다.

⇒ 서버는 데몬이 설치된 컴퓨터

(서버의 역할을 하기 위해서는 고성능과 안정적인 내구성이 필요: 서버급 컴퓨터)

- 포트와 소켓

IP 주소는 인터넷에 있는 특정 컴퓨터까지 오는 데 사용되고, 이때 컴퓨터의 여러 응용 프로그램들을 구분하기 위해 전송 계층이 사용하는 주소를 포트라고 한다.

• IP 주소는 아파트의 동 번호, 응용 프로그램들의 주소는 우리집의 호수

포트 번호의 크기는 16bit ⇒ 각 컴퓨터에는 0 ~ 65,535 사이의 포트가 존재한다.

운영체제는 0에서 65,535 사이의 빈 포트 번호 중 하나를 네트워크를 사용하려는 프로그램에게 할당하고, 해당 프로그램은 그 포트를 사용해 원격지 호스트와 데이터를 주고 받는다.

⇒ 포트는 전송 계층이 여러 프로그램에게 제공하는 주소인 동시에, 멀티 인터페이스인 것.

→ TSAP = 포트

하나의 호스트에서 여러 프로그램이 각각 포트 번호를 받아 통신하듯, 하나의 서버에도 여러 개의 웹 데몬이 설치되어 있을 수 있다. 이때 데몬들도 포트 번호를 사용한다.

프로그램들은 항상 임의로 할당 받은 자신의 포트 번호를 알려주며 통신을 한다.

클라이언트가 웹 데몬과 처음 통신할 때, 포트 번호를 알아야 통신할 수 있다.

만약 데몬들도 클라이언트처럼 매번 운영체제에 의해 임의로 할당된다면 매번 서버에게 물어봐야하는 번거로움이 생긴다.

⇒ 자주 사용하는 데몬이나 중요한 프로그램의 포트 번호를 고정

⇒ well-known 포트 번호 (잘 알려진 포트 번호)

• url 형식은 프로토콜://도메인 이름:포트 번호
  • http://naver.com:80 이 정확한 주소 (http://, 포트번호는 생략 가능)

이때 네이버처럼 많은 사람들이 몰리는 사이트는 소켓을 통해 원활한 접속을 돕는다.

⇒ 소켓: 같은 포트에 연결되어 여러 명을 동시에 처리할 수 있는 소프트웨어적인 접속 장치

• 소켓 프로그래밍: 네트워크를 이용한 프로그래밍
• 최대 동시 접속자수는 동시에 접속시킬 수 있는 최대 인원이라는 뜻으로 소켓을 얼마나 준비하느냐에 따라 달라진다.
• 소켓 개수가 작으면 클라이언트는 빈 소켓을 얻지 못해 서비스가 지연되고, 서버가 다운된 것처럼 느껴지고, 소켓을 무작정 많이 열면 컴퓨터가 느려지고 서버가 다운될 수 있다.
• 소켓의 개수는 관리자가 결정

Section 02. 연결 설정 및 해제

01. 연결 설정의 어려움

전송 계층은 데이터를 전송하기 전 호스트를 연결하는 작업을 수행한다.

연결 설정은 CR(Connect Request)를 보냄으로써 이루어진다.

• CR을 보내고 데이터를 보낼 때, CR을 보냈다고 해서 호스트 B가 연결을 허락한 것이 아니다. 이런 상태에서 데이터를 보낼 경우 B는 해당 데이터를 무시한다.

  

• 호스트 A가 CR을 보내고, B는 승낙한다는 뜻으로 CR_ACK를 보낸다. 호스트 A는 CR_ACK를 받은 이후부터 데이터를 보낼 수 있는데, CR_ACK가 정상적으로 전송되었는지 B는 알 수 없으며, CR_ACK를 보낸 직후에 도착하는 데이터가 A가 보낸 데이터라는 보장이 없다.

  

호스트 A가 CR을 보내고, 호스트 B는 연결을 승낙한다는 뜻으로 응답 메시지 CR_ACK를 보낸다. 이때 CR_ACK를 받고 데이터를 전송했다는 의미로 데이터를 보낼 때 CR_ACK_ACK를 같이 넣어 보낸다.

• 응답 메시지 CR_ACK를 안 보내거나, 데이터에 CR_ACK_ACK를 넣지 않고 보내면, 각 호스트는 보낸 메시지가 제대로 전송됐는지, 응답한 메시지에 대한 데이터인지 알 수가 없기 때문에 이와 같은 합의를 거쳐야 한다.
• 이 과정은 CR → CR_ACK → CR_ACK_ACK, 3번의 합의를 거쳐 연결이 이루어져 3방향 핸드쉐이크라고 한다.
  • 3방향이어도 문제는 여전히 발생할 수 있지만, 이는 4방향, 5방향 … 으로 늘어나더라도 해결되지 않는다.

02. 연결 설정

TCP에서 연결을 위해 사용되는 CR은 SYN(Synchronize)이다. 연결 설정 시에는 SYN을 주고 받으며 일련번호(seq)로 구분하고, 이때 B가 보내는 연결 설정 응답 SYN을 받으면 ACK를 전송한다.

03. 연결 해제의 어려움

연결을 해제(DR, Disconnection Request)할 때에도 서로간의 합의가 필요하다.

호스트 A가 계속 B에게 데이터를 보내는 중에 B가 일방적으로 DR을 보내게 되고, DR을 받기 이전에 A가 보낸 데이터지만, B는 DR 이후에 온 데이터이기 때문에 처리하지 못하는 문제가 발생한다.

연결 해제 시, 가장 큰 문제는 연결 해제를 위해 보낸 DR이 사라지고, 이때 위조된 데이터가 B에게 도착하는 경우이다.

02. 연결 해제

TCP에서는 FIN(Finalize)이 DR에 해당한다.

연결 설정과 동일하게 3방향 핸드쉐이크를 사용한다.