클라이언트-서버 프로토콜(2)

E-mail (전자메일)

• 이용자 간 메시지 교환
• 이 응용 서비스는 지금까지 본 다른 응용과는 다르다.
• Client/server 프로그래밍은 좀 더 다른 방식으로 구현해야 함
  • 중간에 다른 서버를 필요로 함
• 프로토콜
  • SMTP
  • POP
  • IMAP
  • (SMTP를 주로 사용하고, POP와 IMAP은 나중에 추가된 프로토콜)
• MIME(Multipurpose Internet Mail Extensions) : 컨텐츠 형식
  • (인코딩 해서 보낼 형식임)

이메일 서비스 구조

• MTA Server/Client
  • Message Transfer Agent
    • 메일 보낼 때
• MAA Server/Client
  • Message Access Agent
  • 메일 읽을 때
• UA
  • 메일 클라이언트 (요즘은 web)
• 그림 13.12에서 Alice와 Bob이 이메일을 교환한다.
• 두 이용자는 다른 서버를 통해 연결되었다고 가정

서울 우체국에 편지를 접수하고, 부산 우체국으로 편지가 전달되어 상대방에게 최종적으로 전달되는 것과 유사하다

Example 13.12

그림 13.16은 3개의 메일 전달 단계를 설명

그림에서 데이터 전달 섹션에서 봉투 헤더, 바디 (envelope, header, body)를 나누어 묘사했다 클라이언트는 frouzan@anetwork.com으로 이메일을 보내기 위해 자신의 로컬 메일 서버인 someone.com에 접속 하여 이메일을 서버로 올리는 단계이다. 로컬 메일서버는 이메일 메시지를 다 받은 이후에 spool에 넣고, 이 후에 리모트의 상대 이메일 서버로 보낼 것 이다.

Non-ASCII 인 data가 중간에 껴있어서, ASCII로 바꾸려는 경우이다.

E-mail Security

• 이메일 교환은 이메일 시스템을 위한 두 가지 응용계층 보안 프로토콜을 통해 보호된다
• Pretty Good Privacy (PGP)
• Secure/Multipurpose Internet Mail Extensions (S/MIME)

Telnet

• 우리가 필요로 하는 서비스의 모든 클라이언트/서버 쌍을 갖는 것은 불가능
• 서버의 숫자가 굉장히 많아짐 -> 확장성 문제
• 해결책은 공통의 시나리오를 갖는 클라이언트/서버 프로그램을 만들고, 특별 서비스를 위해 기능을 추가하는 것

로컬/원격 로그인

참고) Local logging은 컴퓨터 시스템에서 발생하는 이벤트나 활동을 로컬 시스템에 기록하는 프로세스를 의미

참고) Remote logging은 시스템의 로그를 로컬 시스템이 아닌 원격 시스템에 기록하는 방법을 의미합니다. 

참고) NVT (Network Virtual Terminal)는 TELNET 프로토콜에서 사용하는 가상 터미널의 표준화된 개념입니다. 이를 통해 서로 다른 시스템 간의 통신을 가능하게 합니다.

2022 기출) Network Virtual Terminal character set format을 간단히 설명하시오. (10)

통신 과정

1. 사용자 입력: 터미널에서 사용자가 입력한 데이터는 로컬 컴퓨터의 TELNET 클라이언트로 전달됩니다.
2. TELNET 클라이언트 처리: TELNET 클라이언트는 데이터를 NVT 캐릭터 형식으로 변환하여 인터넷을 통해 원격 시스템으로 전송합니다.
3. 원격 시스템 수신: TELNET 서버는 NVT 형식의 데이터를 수신하여 Pseudoterminal Driver에 전달합니다.
4. 응용 프로그램 처리: Pseudoterminal Driver는 데이터를 원격 응용 프로그램으로 전달하여 처리합니다.
5. 결과 반환: 응용 프로그램의 출력 결과는 역순으로 로컬 터미널에 표시됩니다.

2023 기출) PC에서 telnet으로 comunix.seoultech.ac.kr에 접속하는 경우, PC 와 DNS 서버, PC와 comunix와의 데이터 전달 과정을 프로토콜, 교환 데이터의 관점에서 설명하라

SSH (Secure Shell)

• Secure Shell (SSH)이 현재 리모트 로그인이나 파일전송 등에 사용되는 안전한 응용 프로그램이지만, 원래는 TELNET을 대치하기 위해 고안된 것임(대치하여 암호화 해준다)
• 2가지 버전 존재
  • SSH-1 : deprecated
  • SSH-2 : 현재 많이 사용

SSH 3 컴포넌트

• SSH-CONN
  • 여러 응용 프로그램간 연결 제공
  • 다중화
• SSH-AUTH
  • 서버에 대해 클라이언트의 인증을 제공
• SSH-TRANS
  • TCP 연결상에 보안을 제공하기 위해 보안변수들을 교환
  • 기밀성, 비밀성, 무결성, 압축

SSH 응용

• SSH가 Telnet의 대치물이지만, 다양한 클라이언트/서버 간에 안전한 영결을 제공하는 범용 프로토콜이라 할 수 있다

DNS (Domain Name Service)

• 인터넷에서 이름과 주소를 매핑하는 디렉토리 서비스 필요
  • (디렉토리 서비스 : 이름을 가지고 원하는 리소스를 알려주는 것)
• 전화망과 비슷
  • 이름 -> 전화번호
• 그림 13.28은 어떻게 TCP/IP의 응용 프로그램에서 이름에서 주 소를 매핑하기 위해 DNS 클라이언트와 DNS 서버를 활용하는 방식을 보여줌

네임 스페이스

• 네임과 IP 주소를 연결하는 공간
• 이름은 유일성 확보
• 각각의 주소를 매핑하는 이름 공간 구성 방식
  • Flat
  • hierarchical (보통 hierarchical함)

인터넷의 DNS

• DNS는 여러 플랫폼에서 사용 가능한 프로토콜
• 인터넷에서 도메인 네임 스페이스 (tree)는 3개의 섹션으로 구성
  • generic domains : com, edu, org, ...
  • country domains : jr, us, ...
  • inverse domains : IP 주소로 이름 찾는 서비스. Deprecated(더 이상 사용X 의미)

Resolution

• Name-address resolution
  • Mapping a name to an address
  • (DNS 서버에 mapping 정보가 있어야 함)
• Resolver
  • DNS 클라이언트
  • 가까운 DNS 서버에 엑세스해 매핑 요청
• DNS 서버가 정보를 가지고 있으면 주소가 해결되고, 없으면 정보 를 얻기 위해 다른 DNS 서버에 문의

(캐시를 둬서 다른 컴퓨터가 한 번 물어본 것을 캐시에 저장했다가, 또 물어보면 저장된 것을 반환해주는 구조)

레코드 리소스

• (DNS 서버에 저장되어 있는 매핑 정보(보통 자기 도메인 내의 정보가 있음))
• 네임 서버는 리소스 레코드의 데이터베이스를 저장
• 리소스 레코드는 5-tuple 구조
  • Domain Name, Type, Class, TTL, Value
  • (Type : v4, v6...)

Example 13.13

유닉스와 윈도우에서, nslookup 명령은 address/name 매핑을 알려준다.(DNS 서버에 쿼리를 날려서 응답을 얻는 것임)

$nslookup www.forouzan.biz
Name: www.forouzan.biz
Address: 198.170.240.179

표준 클라이언트/서버 프로토콜 (1)

WWW and HTTP

• World Wide Web (abbreviated WWW or Web)
  • 가장 많이 사용되는 인터넷 서비스
• Hyper-Text Transfer Protocol (HTTP)
  • 웹 요청과 응답 메시지를 교환하는 프로토콜
  • (보통 웹 요청은 클라이언트가 서버에게, 응답 메시지는 서버가 클라이언트에게)

WWW

• Tim Berners-Lee in 1989 at CERN
  • European Organization for Nuclear Research
• 유럽의 여러 연구자들이 다른 위치에 있는 각자의 연구 자료들을 엑세스하기 위해 고안
• 상용 웹은 1990년 초에 시작

HTTP

• HyperText Transfer Protocol (HTTP)
  • 웹 페이지의 요청과 응답 전달 프로토콜
• HTTP 클라이언트가 요청을 HTTP 서버에게 보내고, 서버가 응답
• HTTP 서버 default 포트 번호 80
  • (값을 따로 지정하지 않으면 80번임)
  • 참고) HTTPS : 443번
• HTTP 클라이언트는 시스템(OS)이 주는 임시할당 포트번호 사용
• HTTP는 TCP 서비스를 이용
  • TCP는 연결지향이고, 신뢰적 프로토콜

Example 13.1

그림 13.2은 비지속(nonpersistent) 연결의 예이다.
클라이언트는 그림 링크를 가진 웹 문서를 엑세스한다. 
웹 문서는 텍스트 파일이고, 그림 파일과 같은 서버에 위치한다.
여기에서 2개의 연결을 필요로 한다. 
각각의 연결에서 연결을 설정하기 위해 3-way 핸드세이크를 필요로 한다. 
연결이 설정된 이후 파일이 전달된다. 
처음 웹 문서 파일을 받은 후, 또 다른 3-way 핸드세이크 이후에 그림 파일이 전달된다.

Example 13.2

그림 13.4는 예제 13.3과 같은 시나리오이지만, 지속(persistent) 연결을 사용한다.
하나의 연결을 통해서 여러 파일을 전달하는데, 각각의 요청과 응답은 같은 연결 안에서 따로 보내진다.

Example 13.3

그림 13.5은 문서를 가져오는 예제.

GET 메소드를 이용하여 경로 /usr/bin/image1의 그림을 가져옴. 
요청 라인은 GET 메소드와 URL을 보여주고, HTTP 버전 1.1을 사용. 
헤더의 2라인은 클라이언트가 GIF나 JPEG 포맷을 받을 수 있음을 나타낸다. 요청 메시지에는 body가 없다.
응답 메시지에는 상태라인과 헤더의 4개 라인이 있다. 
날자, 서버, 컨텐츠 인코딩 (MIME), 문서의 길이 등이다. 
문서의 body는 헤더 다음의 빈 줄 이후에 온다.

Example 13.4

그림 13.6은 서버로 정보를 올리는 예제
(서버로 정보를 올리려면 Body 부분에 내용을 채워서 올려야 함)

PUT 메시지 요청 메시지의 요청라인에 요청메소드(PUT), URL, HTTP 버젼(1.1)이 있다. 
헤더에 4개의 라인이 더 있다. 
빈 줄 이후에 요청 메시지의 바디가 오고, 여기에 서버로 업로드 하는 정보가 있다. 
응답 메시지에 상태라인과 4개의 헤더 정보가 있다. 
빈 줄 이후에 서버가 클라이언트로 정보를 body로 보낼 수 있다.

Example 13.7

2022 기출) 클라이언트 브라우저에서 서버의 index.html 문서를 요 청하고, 서버는 해당 문서를 성공적으로 응답하는 HTTP 메시지 구성 형태를 그리고 설명하라. 클라이언트는 Accept : image/gif, 서버는 Content-length: 500의 헤더만을 갖는다.

들어가기 앞서) 쿠기가 뭔지 알아보자

• 서버가 Client쪽으로 내려보내는 정보
• 이 정보를 Client는 브라우저에 저장하고 있다가 서버에 요청을 보낼 때 마다 쿠기를 넣어서 보낸다
• 이렇게 함으로써 client 구분도 하고, client 상태 추적이 가능해진다

2023 기출) 웹 환경에서 쿠키의 생성과 사용을 자세히 설명하시오

Example 13.8

그림 13.8은 온라인 상점에서 쿠키를 사용하는 이점을 보여준다.

1. 구매자가 BestToy라는 상품을 온라인 상점으로부터 구매한다고 하자. 구매자 컴퓨터의 브라우저(클라이언트)는 BestToy 상점의 서버에게 요청을 보낸다.
2. 서버는 클라이언트를 위한 비어있는 쇼핑카트를 만들고 카트에 ID(12343)를 할당한다. 서버는 클라이언트에게 Toy 그림을 클릭하면 Toy를 선택하는 링크를 가진 응답메시지를 보낸다. 이 응답 메시지는 Set-Cookie 헤더라인을 가지고, 그 값을 12343로 한다. 클라이언트는 브라우저 화면에 그림을 보여주고 쿠키값을 브라우저 내에 저장한다.
3. 클라이언트가 한 Toy를 선택하면, 선택한 Toy에 연결된 URL 을 포함하는 요청 메시지를 서버로 보낸다. 이때, 메시지의 헤더에 전에 받았던 쿠키값을 포함시킨다.
4. 서버는 해당 쿠키 값으로 이용자와 카트를 찾고, 카트에 선택한 물품을 넣고, 클라이언트에게 선택한 물품의 가격 정보를 갖는 페이지를 보낸다.
5. 구매자는 해당 물품을 주문하는 정보를 서버로 보낸다. 이때 , 쿠키도 헤더에 첨가해 같이 올린다.
6. 서버는 쿠키 값을 통해 해당 이용자와 해당카트를 찾아내고, 결재를 한 후에 주문결과를 통보한다.

Example 13.9

그림 13.9는 회사나 학교 같은 로컬 네트워크에서 프락시 서버의 사용예이다.
프락시 서버는 지역 네트워크에 설치한다. 클라이언트(브라우저)가 보낸 HTTP 요청이 생기면, 이 요청은 먼저 프락시 서버로 보내지고, 만일 프락시 서버가 해당 페이지를 가지고 있다면 바로 응답한다. 없는 경우, 프락시 서버가 클라이언트처럼 행동하여 인터넷의 웹서버로 요청을 보낸다. 웹서버로부터 응답이 도착하면, 프락시 서버는 응답을 복사해 캐시에 저장하고, 처음 요청을 보낸 클라이언트에게 보낸다.

추가 정보) 지역에 컴퓨터가 많으면 프락시가 네트워크 요청 중간에 껴서 조절을 해준다. 프락시는 캐시 메모리를 둬서 그 안에 서버에서 오는 데이터를 저장했다가, 다른 클라이언트가 같은 정보를 요청하는 경우 캐시에 있는 걸로 대신 전달해준다.

FTP

• File Transfer Protocol (FTP)는 TCP/IP의 표준 응용 프로토콜
• 하나의 호스트에서 다른 호스트로 파일 복사
• 파일을 한 시스템에서 다른 시스템으로 복사하는 것은 간단하고 쉽지만, 몇 가지 고려해야만 하는 사항이 있다
• Active Mode (제어연결, 데이터 연결 두가지 다 활용)
  • Default. 데이터 연결을 서버가 클라이언트로 시도
  • 포트 21(제어연결), 20(데이터연결) 이용
    • (제어 연결 : 연결을 맺고 명령을 주고 받는데 사용함)
• 그런데 Active mode에서는 서버가 클라이언트 쪽으로 연결을 맺는데, 방화벽 문제를 겪을 수 있음 --> Passive Mode
• Passive Mode
  • 데이터 연결도 클라이언트가 서버로 시도

2개의 연결

• FTP는 2개의 연결을 사용하고, 서로 다른 lifetime을 갖는다
• 제어 연결(control connection)은 전체 FTP 세션기간 동안 존재
• 데이터 연결(data connection)은 각각의 파일 전달기간 동안 만들어지고, 없어진다
  • 데이터 연결은 파일 전달에 대한 명령이 있을때 생성되고, 파일전달 이후에 폐기된다.

제어 연결

• 서버 포트 21번으로 연결
• 제어 연결에서, FTP는 TELNET과 같은 접근방식 이용
  • Telnet에서 사용하는 NVT ACSII 문자 셋을 사용
• 통신은 명령과 응답의 교환으로 구성
  • 이 방식은 한번에 하나의 명령을 보내고 응답을 받으므로, 제 어 연결에 적합
• 각 라인은 CR, LF 두 개의 문자로 종료
  • end-of-line token

데이터 연결

(dir, ls 도 데이터 연결을 통해서 수행됨)

• 데이터 연결은 서버 20번 포트 사용
• 데이터 연결의 생성은 제어 연결과는 다른 방식

1. 클라이언트는 임시 포트로 passive open
2. PORT 명령으로 서버에게 포트번호 전달
3. 서버는 자신의 20번 포트와, 클라이언트가 보내준 포트번호로 가는 연결의 active open

Example 13.10

그림 13.11은 하나의 파일을 가져오는 FTP 예제
제어 연결은 계속 열려있고, 데이터 연결은 열렸다 닫혔다를 반복한다. 
파일은 6개의 섹션으로 나뉘어 전달한다고 가정.
모든 파일 레코드를 전달하고, 서버는 파일 전달을 완료 했다고 알린다. 
클라이언트는 더 이상 가져올 파일이 없으므로 QUIT 명령을 발행하고, 서비스 연결은 종료된다.

Example 13.11

다음은 디렉토리의 목록을 가져와 보여주는 실제 FTP 세션의 예이다.

Passive FTP mode

안전한 FTP

• 처음 FTP 프로토콜을 설계할 때 보안은 큰 이슈가 아니었음
• FTP에서 패스워드로 사용자 인증을 하지만, 이 값은 암호화하지 않은 일반 텍스트로 보내는데, 이것은 공격자에게 노출된다
• 데이터 연결을 통한 데이터의 전달 역시 일반 텍스트로 보내는데, 이 또한 안전하지 않다.
• 안전하게 하려면 FTP 사이에 SSL(Secure Socket Layer)를 두면 된다. (SSL-FTP)
  • (정보 암호화를 해준다)

2023 기출) FTP의 동작을 active/passive 모드별로 자세히 설명하시오. (20)

응용계층 소개(2)

C 반복적 프로그래밍

TCP 반복적 프로그래밍 (서버)

• Scoket()으로 소켓 생성
• Bind()로 지정된 서버 주소와 포트 설정
• Listen()으로 클라이언트로부터의 연결을 기다리는 준비를 함
• Accept()를 호출하면, 연결을 기다림 (block)
• Recv()로 데이터 수신
• Send()로 데이터 송신

TCP 반복적 프로그래밍 (클라이언트)

• Socket()으로 소켓 생성
• Connect()로 지정된 서버로 연결 설정 (block)
  • 연결 완료, 혹은 에러 시 block 해제
• Recv()로 데이터 수신
• Send()로 데이터 송신

Echo 서버 프로그램

Echo 클라이언트 프로그램

Java 반복적 프로그래밍

주소와 포트

• InetAddress class
  • Inet4Address class
  • Inet6Address class
• Port Number : int (32bit)
  • (원래 short 16bit 이지만, int에 넣는다)
  • (16bit의 값이 MSB가 1이면 음수이기 때문에, 양수로 보기 위해서 int에 저장하는 것)
• InetScoketAddress class
  • (IP + Port)

UDP 반복 프로그래밍

• DatagramSocket class
  • send() 메소드
  • receive() 메소드
  • close() 메소드
• DatagramPacket class
  • getAddress() 메소드
  • getPort() 메소드
  • getData() 메소드
  • getLength() 메소드

UDP 서버

패킷을 전송하고 수신하기 위해서 Socket을 거친다

UDP 서버 프로그램

UDP 클라이언트

TCP 반복적 프로그래밍

• ServerSocket class : 연결 설정 listen용 소켓
  • Accept() 메소드
  • Bind() 메소드
  • getInetAddress() 메소드
  • getLocalSocketAddress() 메소드
• Socket class : 데이터 송수신용 소켓
  • Connect() 메소드
  • getInetAddress(), getRemoteAddress() 메소드
  • getPort(), getLocalPort() 메소드
  • getInputStream(), getOutputStream() 메소드

TCP 서버

TCP 클라이언트

응용 계층 소개

• 이용자, 혹은 프로그램(프로세스)에게 서비스 제공
• 프로그램을 위한 다양한 네트워크 서비스 제공
  • 원격컴퓨터접근, 파일전송, 이메일전송, ...

서비스 제공

• 표준(standard) 응용계층 프로토콜
  • (보통 RFC 표준 문서와 절차를 통해서 그 내용을 구현함)
• 비표준(nonstandard, proprietary) 응용계층 프로토콜
  • (개인적인 그룹, 집단에서 자체적으로 구현한 것)

응용계층 패러다임

• Client-server paradigm
  • Traditional paradigm
• Peer-to-peer paradigm
  • New paradigm
• Mixed Paradigm

클라이언트-서버 프로그래밍

• 클라이언트는 통신을 시작하고, 요청을 보내는 프로그램
• 서버는 클라이언트의 요청을 서비스하는 응용 프로그램
• 서비스 유형
  • TCP
    • ex) 웹, 이메일...
  • UDP
    • ex) DNS, 인터넷 전화...
• 서버 동작 구현 방법
  • 반목적(Iterative)
  • 동시적(등시적, Concurrent)
    • (대부분 서버가 동시적임)

API

• Application Programming Interface
• 어플리케이션을 만들기 위한 하위 함수, 프로토콜, 도구들의 집합
  • (보통 OS쪽에서 많이 제공해줌)
• 호출 이름, 파라미터 개수, 타입, 리턴값 등이 정해져 있음
  • (==> 형식이 정해져있다)
• 종류
  • Windows API
  • Socket API
  • OPEN API (Web)

전송계층 사용

• 인터넷에서의 서비스는 한 쌍의 프로세스에 의해 제공
  • 프로세스는 인간이나 프로그램
• 한 쌍의 프로세스는 두 응용계층 간에 직접 연결이 없으므로 전송 계층의 서비스를 필요로 함
• 전송계층 프로토콜은 UDP, TCP, SCTP

UDP 반복적 서비스

실제로는 Concurrent가 대부분이지만 반복적으로 구현해보겠다

• 반복적 서버는 한번에 하나의 클라이언트 요청 처리
  • 요청을 받고, 처리하고, 응답을 보내나서, 다음 요청을 처리
• 하나의 요청을 처리하는 동안에, 다른 클라이언트의 요청이나, 같은 클라이언트의 다른 요청도, 기다려야 함
• 수신되고, 큐에 기다리는 요청은 선입선출 방식으로 처리

반복적 TCP 서비스

• 반복적 TCP 서비스는 자주 사용되지 않음
• 동작이 간단하므로 이 섹션에서 고찰해 봄

동시적 통신

• 등시 서버는 동시에 여러 클라이언트의 요청을 처리
• 다양한 언어가 이 방식을 지원
  • C에서는 여러 자식 프로세스가 각각의 요청을 따로 처리
  • Java에서는 각각의 쓰레드(thread)가 요청을 따로 처리

C 반복적 프로그래밍

일반적 이슈

• 소켓은 송수신 버퍼를 가지지 않는다
  • 데이터를 보내거나 받는 기능이 소켓에 있는 것이 아니다.
• 소켓은 단지 참조 레이블이다.
  • 예)파일핸들
• 버퍼나 변수들은 운영체제 내에 있다.

소켓 구조

• Family
  • PF_INET : IPv4
  • PF_INET6 : IPv6
• Type
  • SOCK_STREAM : TCP
  • SOCK_DGRAM : UDP
  • SOCK_RAW : IP
  • (일반적으로 TCP/UDP를 사용하는데, IP를 RAW로 사용할 수도 있다)
• Protocol
  • 0 : TCP/IP

C header files

UDP 반복적 프로그래밍

여기서 Echo는 클라이언트가 서버에게 데이터를 보내면, 서버는 받은 데이터를 클라이언트에게 그대로 반향시켜 data가 잘 전달됬다는 것을 알려줌

• Echo Client
  • Send a short string of character to server
• Echo Server
  • Echo back to client
• Server 프로그램 동작
  • Scoket()으로 소켓 생성
  • Bind()로 지정된 서버 주소와 포트 설정
  • Recvfrom()을 호출하면 데이터가 올 때까지 블록(block)됨
  • Sendto()로 데이터 송신
• Client 프로그램 동작
  • Socket()으로 서버측 주소로 가는 클라이언트 소켓 생성
  • Sendto(), recvfrom()으로 데이터 송수신
    • (보내고:Sendto 데이터가 올 때 까지 기다림:recvfrom)

서버

클라이언트

전송계층 프로토콜(2)

TCP

TCP에서의 윈도우

• TCP는 각 방향의 데이터 전송에 2개의 윈도우 사용
  • send window
  • receive window
• 하나의 연결에 전체 4개의 윈도우 존재

수신 window

• 수신측이 송신측에서 data를 받으면 close하고,
• 프로세스가 수신측에 있는 data를 pull하면 open이 발생한다

흐름 제어 (Flow control)

• 흐름제어는 소비자가 데이터를 이용할 수 있는 속도로 생산자가 데이터를 보내도록 맞추는 것
• TCP는 흐름제어와 오류제어를 분리
• TCP 흐름제어 설명에서 오류는 없는 것으로 가정

Example 10.18

다음 페이지 예제 10.18은, 수신 윈도우(rwnd)를 잘못 축소시킨 예.
파트 a에서 rwnd=12이고, ackNo=206 
파트 b에서 송신측은 206-214 패킷 보냄. 
수신측이 ackNo=210, rwnd=4를 보냄. 
송신측은 206-209은 확인응답 되었으므로 버퍼에서 삭제하고, 
rwnd=4이므로, 210-213까지 보낼 수 있으나 214 를 이미 보냈음 => 문제가 생김. 
214번은 윈도우의 바깥번호가 되버림. 
(210 + 4 < 206 + 12)는 다음식을 만족 안시키는 상황 

(new ackNo + new rwnd >= last ackNo + last rwnd) 

수신측에서 윈도우를 축소시킬때는 위식을 만족하는 범위로 축소해야 한다.

advertisement : 수신 가능한 데이터의 양을 알린다

(new ackNo + new rwnd >= last ackNo + last rwnd) 를 만족해야 한다

오류제어(Error Control)

• TCP는 신뢰적인 전송계층 프로토콜
• TCP를 이용하는 응용 프로그램은 TCP가 순서에 맞게 오류 없이 유실되거나 중복없이 잘 전달되는 것에 의존함

• Ready 상태
  • Time-out 발생
    • 큐에 있는 첫 번째 세그먼트 재전송
  • corrupted Ack 도착
    • 버린다
  • duplicate Ack 도착
    • dupNo == 3 이면 큐 맨 앞에 있는 세그먼트를 재전송하고
    • 타이머 재시작
    • dupNo = 0으로 설정
  • 프로세스로 부터 여러 바이트 데이터를 받음
    • Segment를 만든 후 세그먼트의 복사본을 큐에 저장하고 수신측에 보낸다
    • 만약 이 세그먼트가 큐의 첫 세그먼트라면, 타이머를 시작
    • Sequence number += data length
  • 에러가 없는 올바른 Ack가 도착
    • 윈도우를 ackNo로 Slide 하고, 윈도우 크기를 조정
    • 큐에서 세그먼트를 삭제한다
    • 큐에 다른 세그먼트가 남아있다면 타이머를 다시 시작한다
• Ready -> Blocking
  • Window full
• Blocking 
  • Blocking 상태라 프로세스로부터 데이터를 받지 못하는 것을 제외하면 Ready와 동일

• 항상 Ready 상태
  • 프로세스가 데이터를 달라고 요청하면 데이터를 전송하고 window slide 및 window size 조절
  • 오류는 없지만 중복된 세그먼트가 오거나, 윈도우 범위를 넘어서는 sequence number를 가진 세그먼트가 도착하면
    • 그 세그먼트는 버린다
    • 도착해야할 시퀀스 넘버 동일한 ackNo를 가진 ack를 보낸다
  • 오류있는 segment가 도착하면 그 세그먼트는 버린다
  • 오류는 없지만 순서에 맞지 않는 세그먼트가 도착하면,
    • 중복되지 않는다면 세그먼트를 저장한다
    • 도착해야할 시퀀스 넘버 동일한 ackNo를 가진 ack를 보낸다
  • Ack-delaying timer가 만료되면, delayed ACK를 보낸다
  • 제대로 세그먼트가 도착하면
    • 버퍼에 메시지 저장
    • 수신측 Rn += data length(받아야 할 번호)
    • 만약 Ack Delaying 타이머가 작동중이라면, 타이머를 정지하고  누적된 Ack를 보낸다
      • Ack Delaying timer가 작동중이지 않으면, 작동시킨다

TCP Congestion Control

혼잡이 생기면 트래픽을 줄여야 하고, 이에 따라 윈도우 크기를 줄이게 된다

이후 정상 상태가 되면, 다시 윈도우의 크기를 키워준다

• Cwnd : congestion window
  • 실제 윈도우 크기 = min(cwnd, rwnd)
  • (보통 송신이 수신쪽에 맞추는데, 애초에 송신 버퍼 자체가 수신 버퍼보다 작은 경우도 고려해주는 것이다)
• 혼잡 검출
  • Time-out : strong congestion 신호
  • 3 Duplicated ACK (총 4개의 ACK) : weak congestion 신호 (중간에 뭔가 유실된 것)
• 혼잡 정책(policy)
  • Slow start : exponential increase
    • (윈도우 사이즈를 처음에 작은 값으로 시작하고, 상태가 괜찮으면 빠르게 윈도우 크기를 늘린다)
  • Congestion avoidance : additive increase
    • (additive는 exponential보다 천천히 증가시킴)
  • Fast recovery(optional) : additive increase, 중복 ACK 수신시

Slow Start

• Exponential increase
• cwnd=1로 시작 (MSS=1). Maximum segment size
• ACK 하나올때마다 1 증가 : 지수적 증가
  • ACK 올 때 마다, cwnd = cwnd + 1
  • (세그먼트 하나에 해당하는 ACK 하나 마다 1씩 증가하기 때문에, 지수적으로 증가한다)
• cwnd가 ssthresh (slow start threshold)값이 되면, slow start는 중지하고 다음 단계가 시작이 됨
• 하나의 ACK로 여러 개의 세그먼트를 ACK하는 경우 1만 증가됨

Congestion Avoidance

• Additive increase
• Slow start 단계에서 cwnd=ssthresh가 되면 들어가는 단계
• 송신윈도우의 전체 세그먼트가 ACK되면 1 증가
  • ACK 수신시, cwnd = cwnd + (1/cnwd)
• 혼잡 발생시 Congestion Avoidance는 중지하고, 다른 단계로 넘어감

Fast Recovery

• Optional
  • Old version은 사용 안함
  • 새 버전은 사용하려 함
• 3개의 중복 ACK 수신시 Fast Recovery 단계 시작

Fast Recovery 단계에서

• 새 ACK 수신시 Congestion avoidance로 감
• Timeout시 Slow start로 감
  • cwnd=ssthresh+3
• 중복 ACK 수신시 Fast Recovery에 남아 있음
• Additive increase
  • 중복 ACK 수신시, cwnd = cwnd + (1/cwnd)

TCP Congestion Policy

참고) 아래 Taho와 Reno, New Reno는 리눅스 버전 이름임

• Taho TCP
  • Slow start와 congestion avoidance 사용
• Reno TCP
  • Slow start와 congestion avoidance, Fast recovery 사용
• New Reno TCP
  • Slow start와 congestion avoidance, Fast recovery 사용
  • 추가 Optimization 알고리즘 사용

• Slow start
  • Ack가 도착하면 cwnd는 지수적으로 증가 (+= 1)
  • time-out이 발생하거나 3개의 중복된 ACK가 도착하면 ssthresh를 현재 cwnd의 절반으로 줄이고, cwnd를 1로 설정
• Slow start -> Congestion avoidance
  • cwnd >= ssthresh인 경우
• Congestion avoidance
  • 새로운 ACK가 도착하면, additive increase를 한다
• Congestion avoidance -> Slow start
  • time-out이 발생하거나 3개의 중복된 ACK가 도착하면 ssthresh를 현재 cwnd의 절반으로 줄이고, cwnd를 1로 설정

Example 10.9

그림 10.32는 Taho TCP에서의 혼잡제어의 예.
TCP는 ssthresh를 16 MSS, cwnd = 1로 하는 slow-start (SS)로 시작 
=> congestion window는 지수적으로 증가하고, threshold에 도달하기 전 3번째 RTT에서 timeout 발생.
TCP는 네트워크에 혼잡이 있다고 가정하고 ssthresh = 4 로 설정(혼잡전 MSS는 8이므로, 반으로 줄임)하고, 
cwnd=1로 하는 새로운 slow start (SA) 상태로 시작.

(계속) congestion grows는 다시 지수증가하고, 이 값이 threshold 값은 4가 됨 
=> TCP는 congestion avoidance (CA) 상태로 들어가고, 
congestion window는 cwnd = 12 MSS가 될 때 까지 합산(additive) 증가.
Ssthreshold에 도달하기 전에, 3개의 중복 ACK가 도착 => 혼잡신호. 
TCP는 ssthresh 값을 현재(12)의 반인 6 MSS로 하고 새 slow-start (SS) 시작.
Cwnd=1에서 지수로 증가하다가 Cwnd=ssthresh(6)값이 되면, 
TCP는 congestion avoidance(CA) 상태가 되고 cwnd는 additive 증가.

• Taho랑 큰 차이점이라면, 3 dupACK를 Fast recovery 상태에서 처리한다는 것이다.
• dupACK가 도착하면 cwnd를 1만큼 증가시킨다

Example 10.10

그림 10.34는 Reno TCP의 예

RTT 13까지는 Taho TCP와 같음. 
3개의 중복 ACK가 도착하면, Reno TCP는 ssthresh를 6 MSS로 감소시키고, 
cwnd를 1이 아닌, 더 큰 값인 9(ssthres h+3=9 MSS)로 한다. 
상태는 slow start가 아닌 fast recovery로 간다.

RTT 15까지 두개의 중복 ACK 도착. 
Cwnd는 합산증가하다가, 새로운 ACK (중복아닌)가 도착하면 congestion avoidance 상태로 이동하고, 
cwnd=6 MSS(현재 12의 반값)으로 설정

헷갈렸던 부분) 

문제에서 RTT 15까지 2개의 중복 ACK가 온다고 했다.

RTT 14에서는 첫 번째 중복 ACK가 와서 9->10이 되고

RTT 15에서는 두 번째 중복 ACK가 와서 10->11이 되고, 또 new ACK가 오기 때문에 11-> 12, 그래서 최종적으로 cwnd는 12 MSS가 되는 것이다.

2023 기출) Tahoe TCP와 Reno TCP의 FSM을 그리고, 차이점을 설명하라.

AIMD

• Additive increase, Multiplicative decrease
• 현재 Reno 버젼을 많이 사용
• 장기적으로 보면, 대부분의 상태는 additive increase 상태이고, 혼잡이 방생하면 cwnd 값은 반으로 떨어진다.
• Saw tooth pattern (톱니형상)
• (대부분 additive increase 상태이고, 혼잡발생으로 multiplicative decrease가 발생해서 그래프가 톱니처럼 그려진다)

TCP Throughput

• Throughput = cwnd / RTT
• Saw Tooth에서 max는 min의 2배값
• Throughput = [max cwnd + min cwnd] / RTT
• Throughput = 0.75 [max cwnd] / RTT

Example 10.11

그림 10.35에서 MSS = 10 KB (kilobytes) 이고 RTT = 100 ms인 경우, throughput은 다음과 같다.

Cwnd가 다음과 같은 주기를 가짐 : 10, 12, 10, 8, 8

TCP 타이머

• 4개의 타이머
• Retransmission timer
  • RTO(retransmission timeout, 세그먼트 응답 대기시간)시 재전송
• Persistence timer
  • 큐가 비면 시작. 타임아웃시 probe 세그먼트 전송(1바이트)
  • (보내는 시스템에서 더 이상 보낼 게 없을 때, 아무것도 안보내면 데이터 연길이 끊어질 수 있기 때문)
• Keepalive
  • timeout(2시간)되면, probe 10개 보내고 응답없으면 연결 종료
• TIME-WAIT
  • 연결 종료 ACK 보내고, 2 MSL(maximum timeout lifetime)기간 동안 기다리는 기간.
  • (나는 연결종료 했지만, 상대가 나에게 보낼게 남아있을 수 있다)

RTT(Round Trip Time), RTO 계산

RTT : ack 받은 시각 - 데이터 보낸 시각

• Measured RTT (RTTm)
  • 세그먼트 전송 -> ACK 수신 시간
  • (RTT는 수시로 변하기 때문에, 평균적인 RTT를 구하는게 아래 Smoothed RTT)
• Smoothed RTT (RTTs)
  • RTTs = (1-a)RTTs(이전RTTs) + a*RTTm. a=1/8
• RTT Deviation (RTTd)
  • RTTd = (1-b)RTTd(이전RTTd) + b*|RTTs – RTTm|. B=1/4
• RTO(Retransmission Timeout)
  • RTO = RTTs + 4*RTTd

Example 10.12

그림 10.16은 연결 설정과 데이터 전송 국면의 일부이다.

Exponential Backoff와 Karn 알고리즘

• Exponential Backoff
  • 재전송시 RTO는 2배로
  • 다시 재전송시 RTO를 두배로 (최초의 4배가 됨)
• Karn의 알고리즘
  • 재전송때는 RTT 측정 안함
  • RTT 업데이트도 안함

Example 10.13

그림 10.37은 앞의 예제의 연속인데, 재전송과 Karn의 알고리즘이 적용되었다. 
그림에서 첫번째 세그먼트가 전송되었으나 유실됨. 
RTO 타이머가 4.74초 이후에 아웃됨. 
세그먼트는 재전송되고, RTO는 9.48로 설정됨 (2배) 
터임아웃되기전에 ACK 도착함 
칸의 알고리즘에 따라 RTO 계산은 하지 않음

Options

• TCP Header는 40바이트까지 옵션 가능

SCTP

• Stream Control Transmission Protocol (SCTP)
• 새로운 전송계층 프로토콜
• 멀티미디어 통신을 위해 UDP와 TCP 특징 조합

SCTP 서비스

• 프로세스간 통신 지원
• 다수의 스트림 지원 (데이터, 음성, 영상, ...)
  • (이러한 데이터, 음성, 영상을 하나의 연결로 전송한다는 것이다)
  • (cf) TCP는 하나의 스트림을 지원한다)
• Multihoming : 2개 이상의 연결 동시 지원
  • 통신은 1개만 사용, 다른 것은 백업용
  • (하나의 네트워크 말고도 다른 네트워크로도 연결한다는 말)
• 전이중 통신 지원
• 연결지향 서비스
• 신뢰적 서비스

SCTP 특징

• Transmission Sequence Number(TSN)
• Stream Identifier(SI)
• Stream Sequence Number(SSN)

패킷 포맷

• 패킷 구성
  • general header
  • a set of blocks(chunks)
• 2종류의 Chunks
  • control chunks : association(결합)을 제어, 유지
    • association에 대해서는 뒤에 나온다
  • data chunks : 데이터 운반
• Control chunks 이후 Data chunks

SCTP Association

• Association (결합)
  • Connection in SCTP

참고)

• VT(Verification Tag)
  • 클라이언트가 INIT 메시지를 보낼 때 VT를 포함하여 보내고, 서버가 이에 응답할 때 자신의 VT를 포함한다
  • 초기 VT는 0임

참고) cumTSN : 수신한 모든 데이터의 TSN 합

흐름 제어

• SCTP에서, 데이터의 바이트와 청크 2개를 다루어야 함
  • Rwnd와 cwnd 값은 바이트 단위
  • TSN과 acknowledgment는 청크 단위

오류제어

• SACK chunk를 통해 수신 버퍼의 상태를 송신자에게 알림

전송계층 프로토콜(1)

전송계층 프로토콜 소개

전송계층 프로토콜 서비스

• UDP
  • 비신뢰적 비연결형
  • 간단. 효율적 : 에러처리는 응용계층에서 수행
• TCP
  • 신뢰적인 연결지향
• SCTP
  • UDP와 TCP의 특징을 결합

포트번호(Port Numbers)

• TP 계층 프로토콜은 프로세스간 통신 지원
• 포트 번호는 전송계층에서 종단간 종단간 주소를 지원
  • 프로세스를 구분할 때 구분자를 제공해준다
• 다중화/역다중화 지원

참고)

0~65535 까지 할당이 가능하다

0~1023은 잘 알려진 포트로, 사용하지 않는 것이 좋음

UDP

• User Datagram Protocol
• UDP는 비연결, 비신뢰적 전송 프로토콜
• 최소한의 오버헤드를 가지는 단순 프로토콜

User Datagram

cf) TCP : segment, UDP : datagram

• UDP 패킷 (데이터그램)은 8바이트 고정 헤더
  • 2바이트(16비트) 필드 4개
• 소스 포트번호
• 목적지 포트번호
• Total Length
  • 헤더+데이터
  • 0 - 65535(65k bit)
• Checksum
  • optional

Example 10.1

UDP 헤더값의 16비트 값이 다음과 같을때

CB84000D001C001C

a. source port number => (CB84)16 or 52100

b. destination port number = > (000D)16 or 13
참고로 13번은 보통 서버에서 쓰는 번호다

c. total length => (001C)16 or 28 바이트

d. length of the data => 28-8=20 바이트

e. packet direction => client to server (포트번호 13을 보고 알 수 있음)

f. client process => DayTime client
13번 -> 시간 정보를 요구할 수 있는 프로토콜을 사용한 것

UDP 서비스

• Process-to-Process 통신 : 소켓주소 (IP주소+포트번호)
• 비연결 서비스
• 흐름 제어 : 없다
• 오류 제어 : 체크섬 틀리면 버림
• 체크섬 : 패킷 에러검사
• 혼잡제어 : 없다
• 인캡슐레이션/디캡슐레이션 : 상위계층 데이터 서비스

UDP Checksum

• 3 부분 : Pseudoholder+UDPheader+UDPdata
• Pseudoholder : IP 헤더의 부분
• 모두 더한 다음 1의 보수 -> Checksum

Example 10.2

다음과 같은 경우에 체크섬의 값은?

a. 송신측에서 안 보내기로 함 => 모두 0

b.체크섬 결과가 모두 1=> 보수를 취하면 모두 0 => 다시 보수를 취해 모두 1로 해서 보냄

c.체크섬의 값이 모두0 => 이런 경우는 절대 없음

UDP 응용

• UDP 신뢰적인 전송 프로토콜이 아니지만, UDP는 몇몇 응용에서 선호되고 있다.
• 여러 요인 중에서 최적을 찾아야 한다.
• 예를 들어, 하루내 배송이라는 것과 비용 간의 관계에서 접접을 찾아야 한다.

Example 10.3

DNS 같은 클라이언트/서버 응용은 UDP를 이용하는데,
왜냐하면 클라이언트는 서버에게 짧은 요청을 하고, 서버로부터 빠른 응답을 받기 위함이다.
요청과 응답은 하나의 데이터그램에 딱 들어간다.
--> 각 방향으로 하나의 메시지만을 교환하므로 비연결 속성은 문제가 아니다.
--> 클라이언트/서버는 데이터의 순서가 바뀌는 것이 문제 되지 않는다.

Example 10.4

클라이언트/서버 응용인 SMTP는 전자메일에 사용되는 프로토콜로서, 그림이나 소리, 비디오를 포함하는 멀티 미디어를 보낼 수 있는 e-메일 메시지를 보내기에는 적합하지 않다.
만일 Application이 UDP를 사용하고 메시지가 하나의 UDP 데이터그램에 들어가지 않으면, 데이터는 Application에 의해 여러 데이터그램으로 분할해야한다.
이런 경우에 비연결형 서비스는 문제를 야기한다. 순서가 바뀌어 도착하면 수신자는 정렬이 불가능하다. 이것은 비연결형 서비스는 긴 메시지의 전송에 불리하다는 것을 말한다.

Example 10.5

인터넷에서 긴 텍스트 파일을 다운로드한다고 하자.

이 경우 신뢰적인 전송 서비스가 절대적으로 필요하다. 파일의 부분이 유실되거나 손상되는 것은 안된다.
데이터를 교환하는 부분 사이의 지연은 큰 문제가 아니다. 파일의 모든 데이터가 모아져 볼 수 있을 때까지 기다려야 한다.
이런 경우에 UDP는 전송 계층에 적합하지 않다.

Example 10.6

스카이프 같은 실시간 인터낵티브(real-time interactive) 응용을 사용한다고 하자.

오디오나 비디오는 프레임에 나누어 들어가고 순서대로 보내진다. 만일 전송계층이 손상되거나 유실된 데이터를 재전송하면 전체 송신의 동기를 잃어버린다. 갑자기 빈 화면이 뷰어의 화면에 보일 것이고 다음 프레임이 올 때까지 기다려야 한다. 만일, 각각의 부분이 하나의 데이터그램으로 보내진다면, 수신 UDP는 손상되거나 유실된 패킷을 무시하고 나머지를 보낼 것이다. 그때의 화면은 잠시 빈 화면일 것이고, 대부분의 뷰어는 알아채지도 못할 것이다.

참고)

최근에 HTTP 3에서 TCP의 SYN, SYN+ACK, ACK와 같은 동작을 최적화 하기 위해서 UDP가 각광받고 있다고 한다

TCP

• Transmission Control Protocol (TCP)는 연결지향형의 신뢰적인 프로토콜
• TCP는 명확하게 연결지향 서비스를 제공하기위해 연결설정, 데이터 전달, 연결종료 등의 단계를 제공한다.
• TCP는 신뢰성을 제공하기 위해 GBN과 SR 프로토콜을 조합하여 이용한다.

TCP 서비스

• 프로세스간 통신
• 스트림 전달 서비스 (스트림 형의 데이터란 부분 부분이 연관되어 있는 데이터를 말함)
  • 송수신 버퍼
  • 세그먼트(Segment) : 패킷에 넣은 일련의 바이트 (자른 것 하나 하나)
• 전이중 통신 (full-duplex를 말함. Rx와 Tx와 모두 송수신이 가능함)
• 멀티플렉싱/디멀티플렉싱
• 연결지향 서비스
• 신뢰적 서비스

TCP 특징

• TCP Numbering System
  • Segment 번호가 아닌 바이트 번호 (Octets)

부연설명 하자면, 100MB 중에서 처음 값(랜덤)이 1000번(Byte)이고, 세그먼트 크기가 2000Byte일 때, 두 번째 Sequence number는 3000, 그 다음은 5000....

즉 처음 데이터로부터 얼마나 offset이 떨어져 있는지를 말한다(단순 0, 1, 2, 3 과 같은 번호가 아님)

• Sequence number
  • 보내는 데이터 바이트 번호
  • 처음 값은 랜덤 값
• Acknowledge number
  • 다음에 받기를 기다리는 번호
  • 보통 Offset 번호 다음 번호임(1000이라면 1001)

Example 10.7

세그먼트

• 세그먼트 : TCP 패킷 데이터
• 구성 : 헤더 + 데이터
• 헤더길이 : 20바이트(옵션없음) 에서 60바이트(최대)
• 헤더필드
  • Source/destination port address (16+16 bits)
  • Sequence number (32bits), Acknowledge number (32bits)
  • HLEN (4bits) : 헤더 크기의 word 값(4바이트 배수)
  • Reserved(6), Control(6) : 플래그
  • Window size(16bits) : 송신측 윈도우의 최대 크기 (max 65535바이트)
  • Checksum(16bits) : (IP Placeholder + TCP Header) 체크섬
  • Urgent Pointer(16bits) : 세그먼트내 데이터내의 마지막 긴급데이터 오프셋값
  • Options : 40바이트까지 가능

TCP 연결

• TCP는 연결지향이고, 하나의 메시지에 속하는 모든 세그먼트는 이 논리채널로 보내진다.
• 하나의 논리 채널을 통해 모든 메시지의 전송 및 확인응답과 손상되거나 유실된 프레임의 재전송을 수행한다.
• 비연결형인 IP를 이용하는 TCP가 어떻게 연결지향이 되는가
  • TCP 연결은 물리적이 아닌 논리적인것이다. TCP는 더 높은 수준에서 동작한다. TCP는 IP가 각각의 세그먼트를 수신자에게 전달하는 서비스를 이용하지만, 연결 그 자체를 제어한다.
  • 부연설명 하자면, TCP는 IP를 통해서 통신하는데, IP는 Connectin less임(고정된 경로가 아님). 이걸 가지고 Connection less가 아니냐고 물어본다면, 연결형이 맞다. 가상적인 채널을 통해 흐름, 오류제어를 하고, 신뢰성 있게 전달하기 때문

Urgent Data

• 헤더내 URG 비트가 1이면, 세그먼트내의 처음부터 urgent pointer 값까지 urgent data이고, 그 이후가 정상적인 데이터임

상태 전이 다이어그램

• 연결 설정, 데이터 전송, 연결 해제 간에 발생하는 모든 이벤트를 추적하기 위해, TCP는 유한기계상태(finite state machine, FSM)을 정의하여 사용