네트워크 애플리케이션 개발의 중심은 다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것이다.

예를 들어, 웹 애플리케이션에는 서로 통신하는 서버(웹 서버 프로그램)와 클라이언트(사용자 호스트에서 실행되는 브라우저 프로그램)로 구별되는
두 가지 프로그램이 있다.

중요한 것은 우리가 라우터나 링크 계층 스위치처럼 네트워크 코어 장비에서 실행되는 소프트웨어까지 작성할 필요는 없다는 점이다.
(그렇게 하고 싶더라도 네트워크 코어 장비는 애플리케이션 계층에서 기능하지 않기 때문에 그렇게 할 수 없다.)

애플리케이션 구조는 네트워크 구조와 분명히 다르다.

애플리케이션 개발자 관점에서 네트워크 구조는 고정되어 있고, 해당 애플리케이션의 특정 서비스 집합을 제공한다.

반면, 애플리케이션 구조는 애플리케이션 개발자가 설계하며, 애플리케이션이 여러 종단 시스템에서 어떻게 조직되어야 하는지를 알려준다.

• 항상 동작하고 있는 서버가 존재하고, 클라이언트라는 다른 호스트들로부터 서비스 요청을 받는다.
• 클라이언트는 서로 직접적으로 통신하지 않는다.
• 서버는 잘 알려진 고정 IP 주소를 갖는다.
• 서버가 클라이언트로부터 오는 모든 요청에 더 응답하는 것이 불가능할 때,
  많은 수의 호스트를 갖춘 데이터 센터가 강력한 가상의 서버를 생성하는 역할로 사용된다. 보통, 10만개 정도의 서버를 갖추고 있다.

• 항상 켜져있는 인프라스트럭처 서버에 최소로 의존한다. (혹은 의존하지 않는다.)
• 대신에 애플리케이션은 peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다.
• peer는 흔히 알려진 클라이언트(개인 데스크톱과 랩톱 등등)이다.
• 자가 확장성을 가진다. 예를 들어, 파일 공유 애플리케이션에서는 각 피어들이 파일을 요구하여 작업 부하가 생기지만
  각 피어들은 파일을 다른 피어들에게 분배하여 시스템에 서비스 능력을 갖춘다.
• 데이터 센터 등이 필요 없으므로 비용 효율적이다.

실제 통신하는 것은 프로그램이 아니라, 실행되고 있는 프로그램인 프로세스이다.

2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신한다.

송신 프로세스는 메시지를 만들어서 보내고 수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답한다.

네트워크 애플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성된다.

클라이언트와 서버 프로세스를 다음과 같이 정의한다.

💡 두 프로세스 간의 통신 세션에서
통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트(client)라 하고,
세션을 시작하기 위해 접속을 기다리는 프로세스를 서버(server)라고 한다.

간단히 말하면, 요청을 보내는 쪽의 프로세스를 보통 클라이언트라고 하고, 요청을 받는 쪽을 서버라고 한다.

당연히 P2P 구조에서 봤듯이, 클라이언트도 서버 프로세스가 될 수 있고, 서버도 클라이언트 프로세스가 될 수 있다.

프로세스는 소켓(socket)을 통해 네트워크로 메시지를 보내고 받는다.

네트워크에서 프로세스를 집이라 한다면, 소켓은 마치 문과 같은 존재이다.

위 그림에 보이듯이, 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층간의 인터페이스다.

네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API라고도 한다.

애플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 갖지만, 소켓의 트랜스포트 계층에 대한 통제권은 거의 갖지 못한다.

애플리케이션 개발자의 트랜스포트 계층에 대한 통제

1. 트랜스포트 프로토콜을 선택
2. 최대 버퍼와 최대 세크먼트 크기 같은 약간의 매개변수 설정

프로세스가 다른 수행되고 있는 다른 패킷으로 프로세스를 보내기 위해서는 수신 프로세스가 주소를 갖고 있어야 한다.

수신 프로세스를 식별하기 위해서는 두 가지 정보가 필요하다.

1. 호스트의 주소 즉, IP 주소가 필요하다.
2. 호스트 내의 수신 프로세스를 명시하는 식별자 즉, port 번호가 필요하다. 더 자세한 내용은 3장에서 다룬다.

송신 측의 애플리케이션은 소켓을 통해 메시지를 보내고,
트랜스포트 프로토콜은 네트워크를 통해 그 메시지를 수신 프로세스의 소켓으로 이동시킬 책임이 있다.

인터넷을 포함한 많은 네트워크는 트랜스포트 프로토콜을 하나 이상 제공한다.

트랜스포트 프로토콜이 그것을 이용하는 애플리케이션에게 제공할 수 있는 4가지 서비스를 알아보자.

• 신뢰적 데이터 전송(data integrity)
• 처리율(throughput)
• 시간(timing)
• 보안(security)

1장에서 보았듯이, 패킷들은 컴퓨터 네트워크 내에서 손실될 수 있다.

이러한 데이터 손실은 위험한 결과를 초래할 수 있다.

만약 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 신뢰적 데이터 전송이라고 한다.

트랜스포트 프로토콜이 이 서비스를 제공할 때, 송신 프로세스는 데이터를 소켓으로 보내고 그 데이터가 오류 없이 수신 프로세스에 도착할 것이라는 확신을 갖는다.

트랜스포트 프로토콜이 이 서비스를 제공하지 않을 때 송신 프로세스가 보낸 데이터는 전혀 도착하지 않을 수 있다.

이러한 애플리케이션을 손실 허용 애플리케이션(실시간 비디오/오디오 애플리케이션 등이 대표적)이라고 한다.

다른 세션들이 네트워크 경로를 따라 대역폭을 공유하고, 이 세션들이 생겼다 없어졌다 하기 때문에 가용한 처리율은 시간에 따라 변한다.

트랜스포트 프로토콜은 어느 명시된 속도에서 보장된 가용 처리율을 제공한다.

처리율 요구사항을 갖는 애플리케이션은 대역폭 민감 애플리케이션이라 하고, 현존하는 많은 멀티미디어 애플리케이션은 대역폭에 민감하다.
(너무 처리율이 낮으면 전화같은 서비스가 불가능하다.)

반대로 요구사항이 없는 애플리케이션을 탄력적 애플리케이션(elastic apps)이라고 한다.

트랜스포트 프로토콜은 시간 보장을 제공할 수 있다.

예를 들어, 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 100ms 내에 도착하게 할 수 있다.

실시간 애플리케이션에 주로 사용된다.

송신 호스트에서 트랜스포트 프로토콜은 모든 데이터를 암호화할 수 있고, 수신 호스트에서 트랜스포트 프로토콜은 모두 해독할 수 있다.

보통 TCP를 애플리케이션 계층에서 강화하여 TLS로 보안 서비스를 제공한다. (자세한 내용은 8장에서 다룬다.)

TCP 전송 프로토콜은 다음 세 가지 서비스를 제공한다.

애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하게 한다.

이 핸드 셰이킹(handshaking) 과정이 클라이언트와 서버에 패킷이 곧 도달할테니 준비하라고 알려주는 역할을 한다.

핸드셰이킹 단계를 지나면, TCP 연결이 두 프로세스의 소켓 사이에 존재한다고 말한다.

이 연결은 두 프로세스가 서로에게 동시에 메시지를 보낼 수 있기에 전이중 연결이라고 한다. (3장에서 더 자세히 다룬다.)

통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존한다.

TCP는 애플리케이션의 한 쪽이 바이트 스트림을 소켓으로 전달하면, 그 바이트 스트림이 손실되거나 중복되지 않게 수신 소켓으로 전달한다.

네트워크가 혼잡 상태에 이르면 프로세스의 속도를 낮추는 방법 (또한, 3장에서 자세히 다룬다.)

UDP는 최소의 서비스 모델을 가진 간단한 전송 프로토콜이다.

UDP는 비연결형으로 핸드셰이킹 과정이 없고, 비신뢰적인 데이터 전송 서비스를 제공하여 데이터가 전달되는 것을 보장하지 않는다.

UDP는 또한 혼잡 제어 방식을 포함하지 않아 프로세스의 속도 저하 없이 네트워크를 이용할 수 있다.

그러나 혼잡으로 인해 종단 간 처리율이 낮아져서 속도가 오히려 더 낮아질 수 있다.

TCP와 UDP는 처리율 혹은 시간 보장 서비스를 제공하지 않는다.

시간 민감 애플리케이션 같은 경우에는 이러한 처리율 및 시간 지연에 잘 대처할 수 있도록 설계되어 있다.

그러나 지연이 과도할 때는 보장이 없기 때문에 한계가 있다.

💡 애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다.

이는 다음과 같은 내용을 정의한다.

• 교환 메시지의 타입
• 여러 메시지 타입의 문법(syntax)
• 필드의 의미, 즉 필드에 있는 정보의 의미(semantics)
• 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지를 결정하는 규칙

여러 애플리케이션 계층 프로토콜은 RFC에 명시되어 있어 공중 도메인에서 찾을 수 있다.

예를 들어, 만약 브라우저 개발자가 HTTP 규칙을 따른다면, HTTP 규칙을 따른 어떠한 웹 서버로부터도 웹페이지를 가져올 수 있다.

다른 많은 애플리케이션 계층 프로토콜은 독점이며 공중 도메인에서 찾을 수 없다.

애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐이다.

예를 들어, 웹 애플리케이션은 문서 포맷 표준, 웹 브라우저, 웹 서버, 웹 애플리케이션 계층 프로토콜(HTTP)을 포함하는 여러 요소들로 구성된다.

이 책에서는 중요하고 인기 있는 5개의 애플리케이션 분야에 초점을 맞춘다.

• 웹
• 전자메일
• 디렉터리 서비스
• 비디오 스트리밍
• P2P 애플리케이션

웹은 온디맨드(on-demand) 방식으로 사용자가 원할 때 원하는 것을 수신한다.

개인은 또한, 웹 상에서 많은 정보를 얻고 상호작용할 수 있다.

웹 애플리케이션 계층 프로토콜은 웹의 중심이다.

RFC 1945, RFC 7230, RFC 7540에 정의되어 있다.

HTTP는 메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의하고 있다.

자세히 설명하기 전에 웹 전문 용어들을 알아보자.

웹 페이지들은 객체(object)로 구성된다.

객체는 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML, JPEG 이미지, 자바스크립트 등)이다.

대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성된다.

예를 들어, 웹 페이지가 HTML 텍스트와 5개의 JPEG 이미지로 구성되어 있으면, 이 웹페이지는 6개의 객체를 갖는다.

기본 HTML 파일은 페이지 내부의 다른 객체를 그 객체의 URL로 참조한다.

URL은 객체를 갖고 있는 서버의 호스트 이름과 객체의 경로 이름을 갖고 있다.

e.g.,

http://www.school.edu/picture.gif 

• 호스트의 이름 : www.school.edu
• 경로 이름 : picture.gif

웹 브라우저(Web browser)는 HTTP의 클라이언트 측을 구현하기 때문에, 웹의 관점에서 브라우저와 클라이언트(client)라는 용어를 혼용하여 사용한다.

브라우저는 요구한 웹 페이지를 보여주고 여러가지 인터넷 항해와 구성 특성을 제공한다.

웹 서버(Web server)는 URL로 각각을 지정할 수 있는 웹 객체를 갖고 있다.

일반적으로, 사용자가 웹 페이지를 요청할 때
(1) 브라우저는 페이지 내부의 객체에 대한 HTTP 요청 메세지를 서버에게 보내고,
(2) 서버는 요청을 수신하고 객체를 포함하는 HTTP 응답 메시지로 응답한다.

HTTP는 TCP를 전송 프로토콜로 사용한다.

1. HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작한다.
2. 연결이 이루어지면, 브라우저와 서버 프로세스는 각각의 소켓 인터페이스를 통해 TCP로 접속한다.
3. 클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고, 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다.
   마찬가지로, HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보낸다.

이렇게 TCP를 통해 메시지를 보내면 TCP는 신뢰적인 데이터 전송 서비스를 제공하므로
모든 HTTP 요청 메시지가 궁극적으로 서버에 도착한다. (서버에서 보낸 메시지도 마찬가지다.)

HTTP는 TCP가 어떻게 손실 데이터를 복구하고, 올바른 순서로 데이터를 배열하는지 전혀 걱정할 필요가 없어 계층 구조의 장점이 드러난다.

특정 클라이언트가 몇 초 후에 같은 객체를 두 번 요청해도 서버는 전에 보냈다고 알려주지 않고 객체를 또 보낸다.

HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로, 비상태(stateless) 프로토콜이라고 부른다.

💡 클라이언트-서버 상호작용이 TCP 상에서 발생할 때 각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내지는 것을 말한다.

웹 페이지를 서버에서 클라이언트로 전송하는 단계를 살펴보자.

페이지가 기본 HTML 파일과 10개의 이미지로 구성되고, 이 11개의 객체가 같은 서버에 있다고 가정하자.

연결 수행 과정은 다음과 같다.

1. HTTP 클라이언트는 HTTP 기본 포트 80을 통해 서버로 TCP 연결을 시도한다. TCP 연결과 관련하여 클라이언트와 서버에 각각 소켓이 있게 된다.
2. HTTP 클라이언트는 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 이 요청에 객체 경로도 포함된다.
3. HTTP 서버는 TCP 연결 소켓을 통해 요청 메시지를 받는다. 저장 장치로부터 경로의 객체를 추출한다.
   HTTP 응답 메시지에 그 객체를 캡슐화 하여 소켓을 통해 클라이언트로 보낸다.
4. HTTP 서버는 TCP에게 연결을 끊으라고 한다. (그러나 실제로 클라이언트가 응답 메시지를 올바로 받을 때까지 끊지 않는다.)
5. HTTP 클라이언트가 응답 메시지를 받으면, TCP 연결이 중단된다. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다.
   클라이언트는 응답 메시지로부터 파일을 추출하고 HTML 파일을 조사하여 10개의 JPEG 객체에 대한 참조를 찾는다.
6. 참조되는 JPEG 객체에 대해 1 ~ 4단계를 반복한다.

브라우저는 웹 페이지를 수신하면서, 사용자에게 그 페이지를 보여준다. 다른 브라우저는 웹 페이지를 각기 다른 방식으로 해석하여 보여준다.

HTTP는 통신 프로토콜만 정의할 뿐, 웹 페이지에 대한 관심은 없다.

사용자는 앞의 단계를 동시에 받을지 순차적으로 받을지의 동시성 정도를 조절할 수 있도록 브라우저를 구성할 수 있다.

브라우저는 여러 개의 TCP 연결을 설정하며 다중 연결상에서 웹 페이지의 각기 다른 원하는 부분을 요청할 수 있다.

HTTP 1.0은 비지속 연결을 지원한다.

클라이언트가 HTML 파일을 요청하고 그 파일이 클라이언트로 수신될 때까지의 시간을 측정해보자.

이를 위해 RTT를 알아야 하는데,
RTT(round-trip-time)란 작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 데 걸리는 시간이다.

RTT는 패킷 전파 지연, 큐잉 지연, 처리 지연 등을 포함한다. (1장에 논의되어 있다.)

사용자가 하이퍼링크를 클릭하면, 브라우저와 웹 서버 사이에서 TCP 연결을 시도한다. 이는 3-way handshake를 포함한다.

즉, 클라이언트가 서버로 작은 TCP 메시지를 보내고, 서버는 작은 메시지로 응답하고, 마지막으로 클라이언트가 다시 서버에 응답한다.

서버가 작은 메시지로 응답하면 한 RTT가 계산된다. 이때, 클라이언트는 HTTP 요청 메시지를 TCP 연결로 보내면서 세 번째 응답 부분을 함께 보낸다.

일단, 요청 메시지가 도착하면 서버는 HTML 파일을 TCP 연결로 보내고 이 요청은 또 하나의 RTT를 필요로 한다.

즉, 대략 총 응답 시간은 2RTT와 HTML 파일을 서버가 전송하는 데 걸리는 시간을 더한 것이다.

1. 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다.
   • TCP 버퍼가 할당되어야 하고, TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 하는데
     이는 수많은 클라이언트들의 요청을 동시에 서비스하는 웹 서버에는 심각한 부담이다.
2. 매번 2RTT를 필요로 한다.

HTTP/1.1 지속 연결에서 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다. (비지속 연결도 지원한다.)

같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내진다.

즉, 같은 서버에 있는 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 보낼 수 있다.

이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들 수 있다. (파이프라이닝, pipelining)

일반적으로 HTTP 서버는 일정 기간 사용되지 않으면 연결을 닫는다.

HTTP의 디폴트 모드는 파이프라이닝을 이용한 지속 연결을 사용한다.

RFC는 HTTP 메시지 포맷을 정의한다.

다음은 전형적인 HTTP 요청 메시지이다.

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

1. ASCII 텍스트로 쓰여 있어 사람들이 읽을 수 있다.
2. 메시지가 다섯 줄로 되어 있고, 각 줄은 CR(carriage return)과 LF(line feed)로 구별된다. 마지막 줄에 이어서 CR과 LF가 따른다.

HTTP 요청 메시지의 첫 줄은 요청 라인이라 부르고, 이후의 줄들은 헤더 라인이라고 부른다.

요청 라인은 3개의 필드, 즉 방식(method) 필드, URL 필드, HTTP 버전 필드를 갖는다.

방식 필드는 GET, POST, HEAD, PUT, DELETE 등의 여러 가지 값을 가질 수 있다.

1. Host
   • 객체가 존재하는 호스트를 명시한다.
   • 이미 호스트까지 TCP 연결이 맺어져 있어 불필요하다고 생각될 수 있지만, 2.2.5절에서 나오는 웹 프록시 캐시에서 필요로 한다.
2. Connection : 이 헤더 라인을 포함함으로써, 브라우저는 서버에게 지속 연결 사용을 원하는지 비지속 연결 사용을 원하는지 전달한다.
3. User-agent : 서버에게 요청을 하는 브라우저 타입을 명시한다.
4. Accept-language : 헤더는 사용자가 객체의 어떤 언어 버전을 원하고 있음을 나타낸다.

GET일 때는 비어있고, POST일 때 사용된다.

POST 메시지로 사용자는 서버에 웹 페이지를 요청하고 있으나, 웹 페이지의 특정 내용은 사용자가 폼 필드에 무엇을 입력하는가에 달려 있다.

폼으로 생성한 요구가 반드시 POST일 필요는 없다. 대신에 흔히 요청된 URL의 입력 데이터를 전송한다.

HEAD 방식은 GET과 유사하다.

서버가 HEAD 방식을 가진 요청을 받으면 HTTP 메시지로 응답하는데, 요청 객체는 보내지 않는다. 흔히 디버깅을 위해 사용된다.

PUT 방식은 웹 서버에 업로드할 객체를 필요로 하는 애플리케이션에 의해 사용된다.

DELETE 방식은 사용자 또는 애플리케이션이 웹 서버에 있는 객체를 지우는 것을 허용한다.

다음은 전형적인 HTTP 응답 메시지를 보여준다.

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)

상태 라인(status line)은 버전 필드와 상태 코드, 해당 상태 메시지를 갖는다.

상태 코드와 메시지

• 200 OK: 요청이 성공했고, 정보가 응답으로 보내졌다.
• 301 Moved Permanently: 요청 객체가 영원히 이동되었다. 이때, 새로운 URL은 응답 메시지의 Location 헤더에 나와있다.
• 400 Bad Request : 서버가 요청을 이해할 수 없다.
• 404 Not Found : 요청한 문서가 서버에 존재하지 않는다.
• 505 HTTP Version Not Supported : 요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.

1. Connection : 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫을지 말지 결정한다.
2. Date : HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간을 나타낸다.
3. Server : 메시지가 어떤 웹 서버에 의해 만들어졌는지 나타낸다.
4. Last-Modified : 객체가 생성되거나 마지막으로 수정된 시간과 날짜를 나타낸다.
5. Content-Length : 송신되는 객체의 바이트 수를 나타낸다.
6. Content-Type : 개체 몸체 내부(Entity body)의 객체가 어떤 타입인지 나타낸다.

HTTP 명세서는 많은 헤더라인을 정의하고 있고, 위는 그 중 일부다.

브라우저는 브라우저 타입과 여러 설정, 캐싱하고 있는지에 따라 헤더 라인을 동적으로 생성하고 웹 서버도 비슷하다.

HTTP 서버는 상태를 유지하지 않는다.

그러나 서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하므로
사용자를 확인하는 것이 바람직할 때가 있는데, 이때 HTTP는 쿠키(cookie)를 사용한다.

over stateless HTTP, cookie provides a state related service layer

1. 웹 서버에 HTTP 요청 메시지를 전달한다.
2. 웹 서버는 유일한 식별 번호를 만들고 이 식별 번호로 인덱싱 되는 백엔드 데이터 베이스 안에 엔트리를 만든다.
3. HTTP 응답 메시지에 Set-cookie: 식별 번호의 헤더를 포함해서 전달한다.
4. 브라우저는 헤더를 보고, 관리하는 특정한 쿠키 파일에 그 라인을 덧붙인다.
5. 다시 동일 웹 서버에 요청을 보낼 때
   브라우저는 쿠키 파일을 참조하고 이 사이트에 대한 식별번호를 발췌하여 Cookie : 식별 번호의 헤더를 요청과 함께 보낸다.

이렇게 웹 서버는 사용자를 식별할 수 있다.

웹 캐시(cache)(프록시(proxy) 서버)는 기점 웹 서버를 대신하여 HTTP 요구를 충족시키는 개체이다.

Goal: satisfy client request without involving origin server

웹 캐시는 자체의 저장 디스크를 갖고 있어, 최근 호출된 객체의 사본을 저장 및 보존한다.

1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.
2. 웹 캐시는 객체의 사본이 저장되어 있는지 확인하고, 저장되어 있다면 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
3. 갖고 있지 않다면, 기점 서버로 TCP 연결을 설정한다.
   이후 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 기점 서버는 웹 캐시로 HTTP 응답 메시지를 보낸다.
4. 웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지를 보낸다. (이때, 이미 설정된 TCP를 통해 보낸다.)

캐시(cache)는 요청과 응답을 모두 하는 클라이언트이면서 서버이다.

• server for original requesting client
• client to origin server

일반적으로 웹 캐시는 ISP(university, company, residential ISP)가 구입하고 설치한다.

1. 클라이언트 요구에 대한 응답 시간을 줄일 수 있다.
   보통 클라이언트와 캐시 사이에 높은 속도의 연결이 설정되어 있어 웹서버 캐시에 객체를 갖고 있다면 병목 현상을 줄일 수 있다.
2. 웹 캐시는 한 기관에서 인터넷으로의 접속하는 링크 상의 웹 트래픽을 대폭 줄일 수 있다.
3. 인터넷 전체의 웹 트래픽을 실질적으로 줄여주어 모든 애플리케이션의 성능이 좋아진다.

• 평균 객체의 크기가 1 Mb이고, 기관 브라우저로부터 기점 서버에 대한 평균 요청 비율이 초당 15 요청이라고 가정하자.
• HTTP 메시지 요청이 무시할만큼 작으므로 네트워크 접속 회선에 어떤 트래픽도 발생시키지 않는다고 가정하자.
• 또한, 접속 회선의 인터넷 부분 라우터가 HTTP 요청을 전달하고 응답을 받을 때까지 평균 소요 시간을 2초라고 가정하자.
  통상 이러한 지연을 인터넷 지연이라고 한다.

총 응답 시간 = LAN 지연 + 접속 지연 + 인터넷 지연

LAN의 트래픽 강도는 다음과 같다.

(15 요청/초) X (1 Mb/요청) / 100 Mbps = 0.15

접속 회선(라우터와 라우터 사이)의 트래픽 강도는 다음과 같다.

(15 요청/초) X (1 Mb/요청) / 15 Mbps = 1

LAN의 트래픽 강도는 많아야 수십 ms의 지연을 야기하므로 LAN 지연을 무시할 수 있지만,
트래픽 강도가 1에 가까워지면 1.4절에서 논의한 것과 같이 회선의 지연은 매우 커지고 한없이 증가한다.

접속 회선의 접속률을 100 Mbps 수준으로 늘리면 트래픽 강도를 0.15로 낮추어 해결할 수 있겠지만, 매우 많은 비용이 들어간다.

웹 캐시를 사용한 예시를 보자.

캐시가 만족시킨 요청의 비율(hit rate)은 일반적으로 0.2 ~ 0.7이며, 이 예시에서는 0.4의 적중률을 가진다고 가정하자.

• 캐시와 클라이언트는 고속 LAN으로 연결되어 있어, 요청의 40%는 캐시에 의해(10ms 이내) 즉시 만족된다.
• 나머지 60%의 요청은 여전히 기점 서버에 의해 만족되어야 하므로 트래픽 강도는 1.0에서 0.6으로 감소한다.

일반적으로 0.8 미만의 트래픽 강도는 작은 지연에 속한다. (2초에 의하면 무시할 수 있는 수준이다.)

이들을 고려한 평균 지연은 다음과 같다.

0.4 X 0.01초 + 0.6 X 2.01초 = 1.2....

많은 캐시가 저렴한 PC에서 실행되는 공개 소프트웨어를 사용한다.

• 콘텐츠 전송 네트워크(CDN)을 통해 웹 캐시는 인터넷에서 점진적으로 중요한 역할을 하고 있다.
• CDN 회사는 인터넷 전역을 통해 많은 지역적으로 분산된 캐시를 설치하고 있으며,
  이를 통해 많은 트래픽을 지역화하고 있다. (전용 CDN을 사용하기도 한다.)

웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 웹 캐시 내부에 있는 복사본이 새 것이 아닐 수 있다는 문제를 야기한다.

복사본이 클라이언트에 캐싱된 이후 웹 서버에 있는 객체가 갱신되었을 수도 있기 때문이다.

💡 HTTP는 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서 캐싱해주는데,
이러한 방식을 조건부 GET(conditional GET) 이라고 한다.

Goal: don't send object if cache has up-to-date cached version

HTTP 요청 메시지가 (1) GET 방식을 사용하고, (2) If-modified-since 헤더를 포함한다면, 그것이 조건부 GET이다.

   브라우저의 요청을 대신해서 프록시 캐시는 요청 메시지를 웹 서버로 보낸다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com

   웹 서버는 캐시에게 객체를 가진 응답 메시지를 보낸다.

HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data data data data data ...)

• 캐시는 요청하는 브라우저에게 객체를 보내주고 자신에게도 객체를 저장한다.
• 중요한 것은 캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장한다는 것이다.

    일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 캐시에 저장되어 있다.
   이 객체는 지난주에 웹 서버에서 수정되었으므로, 브라우저는 조건부 GET으로 조사를 수행한다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24

• If-modified-since 값이 일주일 전에 서버가 보낸 Last-Modified 값과 완벽히 일치한다.
• 이 조건부 GET은 서버에게 If-modified-since에 명시된 값 이후 수정된 경우에만 그 객체를 보내라고 한다.

     변경되지 않았다면,

HTTP/1.1 304 Not Modified
Date: Sat, 10 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)

• 위와 같은 응답을 보낸다.
  데이터가 변화가 없어도 객체를 보내는 것은 대역폭을 낭비하는 것이고, 특히 그 개체가 크다면 사용자가 느끼는 응답 시간이 증가된다.
• 위 응답 메시지는 클라이언트에게 요청 객체의 캐싱된 복사본을 사용하라는 것을 의미한다.

2020년 현재 주요 웹 사이트 천만 개의 40%가 HTTP/2를 지원하고 있다.

HTTP/2의 주요 목표는 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간을 줄이는 데 있으며,
요청 우선순위화, 서버 푸시, HTTP 헤더 필드의 효율적인 압축 기능 등을 제공한다.

HTTP/2는 클라이언트와 서버 간의 데이터 포맷 방법과 전송 방법을 변경했다.

지속적인 연결을 사용할 때 웹 페이지당 오직 하나의 TCP 연결을 가짐으로써,
아래 설명하듯이 서버에서의 소켓 수를 줄이며 전송되는 각 웹 페이지는 공정한 네트워크 대역폭을 가질 수 있다.

그러나 하나의 TCP 상에서 모든 웹페이지를 보내면 HOL(Head of Line) 블로킹 문제가 발생할 수 있다.

비디오 아래 수많은 작은 객체들을 포함할 때 서버와 클라이언트 사이에 저속에서 중간 속도의 병목 링크가 있다고 하자.

비디오 클립은 병목 링크를 통과하는데 오래 걸리는 반면, 작은 객체들은 비디오 클립 뒤에서 기다림이 길어진다.

즉, 비디오 클립이 객체들을 블로킹하게 된다.

HTTP/1.1에서는 여러 개의 병렬 TCP 연결을 열어서 위 문제를 해결해왔다.

TCP 혼잡 제어는 각 TCP 연결이 공정하게 병목 링크를 공유하여 같은 크기의 가용한 대역폭을 공평하게 나누게 해준다.

만일 n개의 TCP 연결이 병목 링크에서 작동하고 있다면, 각 연결은 대략 대역폭의 1/n 씩을 사용하게 된다.

하나의 웹 페이지를 전송하기 위해 여러 개의 병렬 TCP 연결을 열게 함으로써 브라우저는 일종의 속임수로 링크 대역폭의 많은 부분을 받게 된다.

많은 HTTP/1.1 브라우저들은 6개까지 병렬 TCP 연결을 열고 HOL을 막을 뿐만 아니라 더 많은 대역폭을 사용할 수 있게 한다.

HTTP/2의 주요 목표 중 하나는 하나의 웹 페이지를 전송하기 위한 병렬 TCP 연결의 수를 줄이거나 제거하는 데 있다.

이는 서버에서 열고 유지되는 데 필요한 소켓의 수를 줄일 뿐만 아니라 목표한 대로 TCP 혼잡 제어를 제어할 수 있게 하는 데 있다.

그러나 웹 페이지를 전송하기 위해 오직 하나의 TCP 연결만을 사용하게 될 경우에 HTTP/2는 HOL 블로킹을 피하기 위해 신중하게 구현된 메커니즘이 필요하다.

💡 HTTP/2 프레이밍(framing)이란, HTTP 메시지를 독립된 프레임들로 쪼개고, 인터리빙(interleaving)하고, 반대편 사이트에서 재조립하는 것이다.

예를 들어, 비디오 클립과 크기가 작은 객체 8개의 요청이 들어오면, 서버는 9개의 객체를 보내기 위한 TCP 병렬 요청을 받게된다.

이때 (1) 비디오 클립을 1000개의 프레임으로 나누고 (2) 각 객체를 2개의 프레임으로 나누어 비디오 클립으로부터 하나의 프레임을 전송한다.

이후 프레임 인터리빙을 이용하여 각 소형 객체의 첫 번째 프레임을 보내고 이를 반복하여 HOL 블로킹을 피할 수 있다.

HTTP 메시지를 독립된 프레임들로 쪼개고 인터리빙하고 반대편 사이트에서 재조립하는 것이야말로 HTTP/2의 가장 중요한 개선점이다.

프레이밍은 HTTP/2 프로토콜의 프레임으로 구현된 다른 프레이밍 서브 계층에 의해 이루어진다.

서버가 HTTP 응답을 보내고자 할 때, 응답은 프레이밍 서브 계층에 의해 처리되며 프레임들로 나눠진다.

응답의 헤더필드는 하나의 프레임이 되고, 메시지 본문은 하나의 프레임으로 쪼개진다.

응답 프레임들은 서버의 프레이밍 서브 계층에 의해 인터리빙된 후 하나의 지속적인 TCP 연결상에서 전송된다.

프레임들이 클라이언트에 도착하면 프레이밍 서브 계층에서 처음 응답메시지로 재조립되며 브라우저에 의해 처리된다. (클라이언트에서 서버로 요청할 때도 마찬가지이다.)

각 HTTP 메시지를 독립적인 프레임으로 쪼개는 것 외에도 프레이밍 서브 계층은 프레임을 바이너리 인코딩한다.

바이너리 프로토콜은 파싱하기에 효율적이고, 더 작은 프레임 크기를 갖고, 에러에 강하다.

메시지 우선순위화는 개발자들로 하여금 요청들의 상대적 우선 순위를 조정할 수 있게 함으로써 애플리케이션의 성능을 최적화할 수 있게 해준다.

클라이언트가 하나의 특정 서버로 동시에 여러 개의 요청을 할 때, 각 메시지에 1에서 256 사이의 가중치를 부여함으로써 요청에 우선순위를 매길 수 있다.

높은 수치일수록 높은 우선순위를 갖는다.

서버는 가장 높은 우선순위의 요청을 위한 프레임을 제일 먼저 보낼 수 있다.

클라이언트 또한 각 의존도에 따라 메시지의 ID를 지정하여 서로 다른 메시지들 간의 의존성을 나타낼 수 있다.

HTTP/2의 또 다른 특징은 서버로 하여금 특정 클라이언트 요청에 대해 여러 개의 응답을 보낼 수 있게 해주는 데 있다.

처음 요청에 대한 응답 외에도, 서버는 클라이언트의 요청 없이도 추가적인 객체를 클라이언트에게 푸시하여 보낼 수 있다.

이는 HTML 기반 페이지가 웹 페이지를 완벽하게 구동시킬 필요가 있는 객체들을 가리킬 수 있기에 가능하다.

이러한 객체에 대한 HTTP 요청을 기다리는 대신 서버는 HTML을 분석할 수 있고, 필요한 객체들을 식별할 수 있고,
해당 객체들에 대한 요청이 도착하기도 전에 해당 객체들을 클라이언트로 보낸다.

서버는 해당 요청들을 기다리는 데 소요되는 추가 지연을 없앤다.

트랜스 프로토콜인 QUIC(3장에서 다룬다) 위에서 작동하도록 설계된 새로운 HTTP 프로토콜로서, 완전히 표준화된 상태는 아니다.

계층구조는 크고 복잡한 시스템의 잘 정의된 특정 부분을 논의할 수 있게 해주며, 이러한 단순화는 매우 중요하다.

시스템이 계층구조를 가질 때, 그 계층이 제공하는 서비스의 구현을 변경하는 것도 매우 쉽다.

어떤 한 계층의 구현이 변하더라도 시스템의 나머지 부분은 변하지 않는다는 것이다.

💡 계층구조의 각 계층은 (1) 그 계층에서 어떤 동작을 취하고 (2) 그 계층 바로 아래 계층 서비스를 사용함으로써 서비스를 제공한다.

네트워크 프로토콜의 설계 구조를 제공하기 위해,
네트워크 설계자는 프로토콜(프로토콜을 구현하는 네트워크 하드웨어와 소프트웨어)을 계층(layer)으로 조직한다.

즉, 각각의 프로토콜은 한 계층에 속하며, 프로토콜 계층은 소프트웨어, 하드웨어 또는 둘의 통합으로 구현할 수 있다.

• 한 계층은 상위 계층에 제공하는 서비스(service)에 관심을 갖고, 이것을 계층의 서비스 모델(service model)이라고 한다.
• 각 계층은 그 계층 내부에서 어떤 동작을 수행하거나, 직접 하위 계층의 서비스를 사용한다.

다양한 계층의 프로토콜을 합하여 프로토콜 스택(protocol stack)이라고 한다.

인터넷 프로토콜 스택은 5개 계층으로 구성된다.

물리, 링크, 네트워크, 트랜스포트, 애플리케이션 계층

아래부터 1계층 ~ 5계층

💡 네트워크 애플리케이션과 애플리케이션 계층 프로토콜이 있는 곳이다.

• 인터넷의 애플리케이션 계층이 포함하는 대표적 프로토콜은 다음과 같다.
  • HTTP : 웹 문서 요청과 전송 제공
  • SMTP : 전자메일 전송 제공
  • FTP : 두 종단 시스템 간의 파일 전송 제공
• 도메인 네임 서버(domain name server, DNS)는 이 애플리케이션 계층에 존재한다.
• 애플리케이션 계층 프로토콜은 여러 종단 시스템에 분산되어 있어서
  한 종단 시스템에 있는 애플리케이션이 다른 종단 시스템에 있는 애플리케이션과 정보 패킷(메시지, message)을 교환하는 데 이 프로토콜을 사용한다.

💡 클라이언트와 서버 간에 애플리케이션 계층 메시지를 전송하는 서비스를 제공한다.

• 트랜스포트 계층 패킷 = 세그먼트(segment)
• 트랜스포트 프로토콜의 두 가지 종류로는 다음과 같으며, 이들은 애플리케이션 계층 메시지를 전달한다.
  • TCP
    • 애플리케이션에게 연결 지향형 서비스를 제공한다.
    • 목적지로의 애플리케이션 계층 메시지 전달 보장과 흐름 제어(송신자/수신자의 속도 일치)를 포함한다.
    • 긴 메시지를 짧은 메시지로 나누고, 혼잡 제어 기능을 제공한다. (네트워크가 혼잡할 때 출발지의 전송률을 줄임)
  • UDP
    • 애플리케이션에게 비연결형 서비스를 제공한다.
    • 신뢰성, 흐름 제어, 혼잡 제어를 제공하지 않는다.

💡 한 호스트에서 다른 호스트로 데이터그램(datagram, IP의 전송 단위)을 라우팅하는 책임을 진다.

즉, 출발지와 목적지 간 일련의 패킷 스위치(인터넷에서는 라우터)를 통해 데이터그램을 라우트한다.

1. 출발지 호스트에서 인터넷 트랜스포트 계층 프로토콜(TCP 또는 UDP)은 트랜스포트 계층 세그먼트와 목적지 주소를 네트워크 계층으로 전달한다.
2. 네트워크 계층은 목적지 호스트의 트랜스포트 계층으로 세그먼트를 운반하는 서비스를 제공한다.

네트워크 계층은 IP 데이터그램의 필드를 정의하며 종단 시스템과 라우터가 이 필드에 어떻게 동작하는지를 정의하는 프로토콜, IP 프로토콜을 가지고 있다.

• 오직 하나의 IP 프로토콜이 존재한다.
• 네트워크 계층을 가진 모든 인터넷 요소는 IP 프로토콜을 수행해야만 한다.

인터넷 네트워크 계층은 라우팅 프로토콜을 포함한다.

• 라우팅 프로토콜은 출발지와 목적지 사이에서 데이터그램이 이동하는 경로를 결정한다.
• 인터넷은 네트워크의 네트워크이며, 한 네트워크 내부에서 네트워크 운용자는 원하는 어떠한 라우팅 프로토콜이라도 수행할 수 있다.

💡 전체 프레임을 한 네트워크 요소에서 이웃 네트워크 요소로 이동시킨다.

링크 계층 패킷 = 프레임(frame)

경로상의 한 노드(호스트 혹은 패킷 스위치)에서 다른 노드로 패킷을 이동하기 위해 네트워크 계층은 링크 계층 서비스에 의존해야 한다.

1. 각 노드에서 네트워크 계층은 데이터그램을 아래 링크 계층으로 보내고 링크 계층은 그 데이터그램을 경로상의 다음 노드에 전달한다.
2. 다음 노드에서 링크 계층은 그 데이터그램을 상위 네트워크 계층으로 보낸다.

링크 계층에서 제공하는 서비스는 그 링크에서 채용된 특정 링크 계층 프로토콜에 의해 결정된다.

e.g., 어떤 프로토콜은 송신 노드로부터 하나의 링크를 통해 반대편에 있는 수신 노드까지 신뢰적인 전송을 제공한다. (이는 TCP의 신뢰적인 전달 서비스와는 다름)

데이터그램은 출발지에서 목적지로 가는데 여러 링크를 거치므로, 데이터그램은 경로상의 각기 다른 링크에서 다른 링크 계층 프로토콜에 의해 처리될 수 있다.

💡 프레임 내부의 각 비트를 한 노드에서 다음 노드로 이동시킨다.

이 계층의 프로토콜들은 링크에 의존하고, 더 나아가 링크의 실제 전송 매체(꼬임쌍선, 단일 모드 광케이블 등)에 의존한다.

그림은 아래 과정의 물리적 경로를 보여준다.

1. 송신 종단 시스템의 프로토콜 스택 아래로 데이터를 보내며
2. 중간의 링크 계층 스위치와 라우터의 프로토콜 스택을 위아래로 거치고
3. 수신 종단 시스템의 프로토콜 스택 상위로 보낸다.

• 이들은 둘 다 패킷 교환기다.
• 종단 시스템과 비슷하게, 라우터와 링크 계층 스위치는 네트워킹 하드웨어와 소프트웨어를 계층으로 구성한다.
• 그러나 모든 계층을 구현하지는 않고, 일반적으로 하위 계층을 구현한다.
  (그림에서는 링크 계층 스위치가 1, 2 계층을 구현하고 라우터는 1~3 계층을 구현)
• 즉, 인터넷 라우터들은 IP 프로토콜(3계층 프로토콜)을 구현할 수 있지만, 링크 계층 스위치는 불가하다.

이는 다섯 계층 모두를 구현한다.

💡 인터넷 구조가 네트워크의 ‘가장자리’에서 그 복잡성을 유지한다.

💡 각 계층에서 패킷은 헤더 필드와 페이로드 필드(payload field)라는 두 가지 형태의 필드를 갖는다.

페이로드(payload)는 일반적으로 그 계층 상위로부터의 패킷을 말한다.

1. 송신 호스트에서 애플리케이션 계층 메시지(application-layer message, 위 그림에서의 M)는 트랜스포트 계층으로 보내진다.
2. 가장 간단한 경우, 트랜스포트 계층은 메시지에 수신 측 트랜스포트 계층에서 사용될 추가 정보인 트랜스포트 계층 헤더 정보(Ht)를 더한다.

트랜스포트 계층 세그먼트(transport-layer segment) = 애플리케이션 계층 메시지 + 트랜스포트 계층 헤더 정보

• 트랜스포트 계층 세그먼트는 애플리케이션 계층 메시지를 캡슐화한다.
• 트랜스포트 계층 헤더 정보가 포함하는 내용은 다음과 같다.
  • 수신 측의 트랜스포트 계층이 그 메시지를 적절한 애플리케이션으로 보내도록 하는 정보들
  • 메시지의 비트들이 변경되었는지 아닌지를 수신자가 결정하게 하는 오류 검출 비트

1. 트랜스포트 계층은 세그먼트를 네트워크 계층으로 보낸다.
2. 네트워크 계층은 출발지와 목적지 종단 시스템 주소와 동일한 헤더 정보(Hn)를 추가하여 네트워크 계층 데이터그램(network-layer datagram)을 만든다.

1. 데이터그램은 링크 계층으로 전달된다.
2. 링크 계층도 자신의 헤더 정보를 추가하여 링크 계층 프레임(link-layer frame)을 만든다.

캡슐화 과정은 위에서 말한 것보다 더 복잡할 수 있다.

큰 메시지는 여러 개의 트랜스포트 계층 세그먼트로 분할될 수 있으며, 그들 각각은 여러 개의 네트워크 계층 데이터그램으로 분할될 수 있다.

그러고 나서 수신 측에서 각 세그먼트는 분할된 데이터그램들로 재구성되어야 한다.

인터넷의 모든 유용성과 역동성 뒤에,
‘나쁜 친구들’이 인터넷에 연결된 컴퓨터에 해를 끼리고, 사생활을 침해하고, 우리가 의존하는 인터넷 서비스를 동작하지 못하게 함으로써
일상생활을 망가트리려고 하는 어두운 면이 있다.

네트워크 보안 분야는 나쁜 친구들이 어떻게 컴퓨터 네트워크를 공격할 수 있는가와
그러한 공격으로부터 네트워크를 방어할 수 있는가, 혹은 아예 그러한 공격에 영향을 받지 않는 새로운 구조의 설계 등을 다루는 분야다.

우리는 인터넷에서 데이터를 수신/송신하기를 원하기 때문에 장치를 인터넷에 연결한다.

불행하게도 우리에게 전달되는 데이터들 중 해로운 것들도 포함되는데, 이들을 멀웨어(malware)라고 한다.
멀웨어는 우리들의 장치에 들어가서 나쁜 영향을 미친다.

e.g., 파일 삭제, 주민번호, 비밀번호, 키스트로크(keystroke, 키보드를 누르는 것) 등의 사적인 정보를 모으는 스파이웨어를 설치
→ 이러한 정보를 모아 나쁜 친구들에게 인터넷을 통해 다시 보낸다.

면역되지 않은 호스트는 수천의 비슷한 면역되지 않은 장치들로 구성된 네트워크, 즉 봇넷(botnet)에 등록될 수 있다.
나쁜 친구들은 목표로 하는 호스트에 대해 스팸 전자메일 분해 혹은 분산 DoS(Denial of Service) 공격을 위해 이 봇넷을 제어하고 이용한다.

오늘날 널리 퍼져 있는 많은 멀웨어는 자기복제(self-replicating)를 한다.
자기복제 멀웨어는 아래의 방법을 통해 기하급수적으로 퍼질 수 있다.

1. 한 호스트에 영향을 미치면, 그 호스트에서 인터넷을 통해 다른 호스트로의 엔트리를 찾는다.
2. 새롭게 영향을 받은 호스트로부터 또 다른 많은 호스트로의 엔트리를 찾는다.

네트워크, 호스트 혹은 다른 인프라스트럭처의요소들을 정상적인 사용자가 사용할 수 없게 하는 것

웹 서버, 전자메일 서버, DNS 서버, 기관 네트워크는 DoS 공격을 받을 가능성이 있다.

만약 올바른 순서의 패킷을 공격받기 쉬운 애플리케이션 혹은 운영체제에 보내면(교묘한 메시지를 보내는 것을 포함)
그 서비스는 중단되거나, 호스트가 동작을 멈출 수도 있다.

목표 호스트의 접속 링크가 동작하지 못하도록 많은 패킷을 보내서 정당한 패킷들이 그 서버에 도달하지 못하게 한다.

1.4.2절의 지연과 손실 분석 논의를 기억해보자.

만약 서버가 R bps의 접속 속도를 갖고 있다면, 공격자는 피해를 주기 위해 대략적으로 R bps의 속도로 트래픽을 전송하면 된다.

만약 R가 매우 크다면 단일 공격 소스는 서버에 나쁜 영향을 줄 수 있는 충분한 트래픽을 발생시킬 수 없다.

더 나아가, 모든 트래픽이 하나의 소스에서 방사된다면 업스트림 라우터는 그 공격을 발견할 수 있고
트래픽이 서버에 가까이 가기 전에 그 소스로부터 모든 트래픽을 차단(block)할 수 있다.

아래 그림처럼 분산 DoS(DDoS) 공격에서 공격자는 다중의 소스를 제어하고 각 소스는 목표에 트래픽을 보낸다.

이런 방법으로 모든 제어 소스에 걸친 통합 트래픽 속도가 서비스를 무능력하게 하기 위해서는 전송률이 약 R이어야 한다.

수천개의 호스트로 구성된 봇넷을 이용하는 DDoS 공격은 오늘날 매우 흔하다.

목표 호스트에 반열림(half-open) 혹은 전열림(fully open)된 TCP 연결을 설정한다.

호스트는 가짜 연결을 처리하느라 바빠서 정상적인 연결을 받아들이는 것을 중단하게 된다.

컴퓨터 네트워크 설계자는 DoS 공격을 방어하기 위해 무엇을 할 수 있는가?

→ 세 가지 유형의 DoS 공격에는 각기 다른 방어가 필요하다.

유비쿼터스(ubiquitous) 인터넷 접속은 매우 편리하고 이동 사용자를 위한 애플리케이션이 가능하지만, 인터넷 접속은 주요한 보안 취약성을 창출했다.

무선 전송장치의 근처에 수동적인 수신자 즉, 패킷 스니퍼(packet sniffer)를 위치시킴으로써 그 수신자는 전송되고 있는 모든 패킷의 사본을 얻을 수 있다.

스니퍼는 무선 뿐만 아니라, 유선 환경에서도 배치될 수 있다.
(이더넷 LAN, 케이블 접속 기술, 인터넷에 연결되는 기관의 접속 라우터 혹은 접속 링크 등)

나쁜 친구들은 이렇게 가로챈 패킷을 오프라인으로 분석하여 비밀번호, 주민등록번호, 영업 비밀 등 모든 종류의 민감한 정보를 얻을 수 있다.

패킷 스니퍼는 수동적이기 때문에, 즉 스니퍼는 채널에 패킷을 삽입하지 않기 때문에 이를 탐지하기가 어렵다.

그래서 무선 채널로 패킷을 보낼 때 어떤 나쁜 친구가 우리 패킷의 사본을 기록하고 있을 수 있다는 가능성을 받아들여야 한다.

패킷 스니핑을 방지하기 위한 가장 좋은 방어는 암호화를 포함하는 것이다. (8장에서 다룸)

임의의 출발지 주소, 패킷 내용, 목적지 주소를 갖는 패킷을 생성하고 이 패킷을 인터넷으로 보내는 것은 매우 쉽다.

가짜 출발지 주소를 가진 패킷을 인터넷으로 보내는 능력을 IP 스푸핑(spoofing)이라고 하며,
한 사용자가 다른 사용자인 것처럼 행동하는 여러 가지 방법 중 하나다.

이 문제를 해결하기 위해서는 종단 인증(end-point authentication),
즉 메시지가 실제로 와야 할 곳으로부터 온 것인지 확신할 수 있는 방법이 필요하다.

네트워크 애플리케이션과 프로토콜의 경우 어떻게 이것을 할 수 있을까? (8장에서 다룸)

인터넷은 처음에 어떻게 보안 문제에 직면하게 되었을까?

인터넷은 원래 ‘투명한 네트워크에 연결된 상호 신뢰할 수 있는 사용자 그룹’ 모델,
즉 보안이 필요 없는 모델에 기반을 둔 방식으로 설계되었다. [Blumenthal 2001]

따라서 원래 인터넷 구조의 많은 특성은 이러한 상호 신뢰를 반영하고 있다.
e.g., 한 사용자가 패킷을 다른 사용자에게 보내는 능력은 default, 사용자 식별은 default로 인증해야 하는 것보다는 선언된 액면 그대로 믿는 것이다.

그러나 오늘날 인터넷은 ‘상호 신뢰하는 사용자’를 분명히 포함하지 않는다.

그럼에도 불구하고 오늘날의 사용자들은 서로를 꼭 신뢰하지는 않을 때, 익명으로 통신하기를 원할 때,
제3자를 통해 간접적으로 통신할 때(이동 지원 에이전트, mobility-assisting agent) 등 이러한 상황에서도 여전히 통신이 필요하다.

아직 우리 앞에는 많은 보안 관련 해결 과제가 존재한다.

우리는 스니핑, 종단 위장(end-point masquerading), 중간자 공격, DDoS 공격, 멀웨어 등에 방어하는 방법을 찾아야 한다.

💡 상호 신뢰하는 사용자 간의 통신은 일반적인 것이 아니라 예외적인 것임을 명심해야 한다.

1960년대 초의 세계 주요 통신 네트워크는 전화망이었다.

전화망이 송신자에게서 수신자로 정보를 전송하는 데 회선 교환을 사용하였다. (음성이 송수신자 간에 일정한 속도로 전송된다면 이는 적절한 선택)

각 사용자가 만드는 트래픽은 집중적(bursty)이었다.

즉, 원격 컴퓨터에 명령을 내리는 활동과 응답을 기다리고 응답을 검토하는 비활동 사이의 기간이 일정하지 않았다.

세계적으로 3개의 연구 그룹이 회선 교환을 대신할 수 있는 효율적이고 견실한 방법으로서 패킷 교환의 개념을 창안하였다.

• 1967년, 로렌스 로버츠(Lawrence Roberts)는 ARPAnet에 대한 대략의 계획을 발간하였다.
  → 첫 번째 패킷 교환 컴퓨터 네트워크이자 오늘날 공중 인터넷의 직계 원조
• 1969년, 첫 번째 패킷 스위치가 UCLA에 설치되었다.
• 1972년, ARPAnet은 약 15개의 노드로 커졌다.
  ARPAnet 종단 시스템 간에 NCP(Network-Control Protocol)라고 하는 첫 번째 호스트 간(host-to-host) 프로토콜이 완성되었다. [RFC 001]

종간 간에서 프로토콜을 사용할 수 있게 되자, 애플리케이션을 개발할 수 있게 되었다.

• 1972년, 레이 톰린슨(Ray Tomlinson)이 최초의 전자메일 프로그램을 만들었다.

초기 ARPAnet은 단일 폐쇄 네트워크였다.

즉, ARPAnet 호스트와 통신하기 위해서는 다른 ARPAnet IMP에 실제로 접속해야 했다.

1970년대 중반 초, ARPAnet과 별개의 패킷 교환 네트워크들이 생겨났다.

• DARPA의 패킷 위성 [RFC 829]
• 패킷 라디오 네트워크 [Kahn 1978]
• ALOHAnet : 하와이에 위치하는 대학들을 함께 연결하는 마이크로파 네트워크 [Abramson 1970]
• Cyclades : 루이 푸장(Louis Pouzin)이 이끈 프랑스 패킷 교환 네트워크 [Think 2012]
• 시분할 네트워크 : 1960년대 후반에서 1970년대 초반의 네트워크 [Schwartz 1977]
  e.g., Tymnet, GE Information Services 네트워크

네트워크 수가 증가함에 따라
네트워크를 연결하는 포괄 구조(상호연결 네트워크, 네트워크의 네트워크)의 개발 시기가 점차 다가왔다.

이러한 구조 원리는 TCP 프로토콜로 구체화되었다.

이는 아래의 두 가지를 결합한 것이며, 오늘날의 TCP와는 매우 다르다.

• 종단 시스템의 재전송을 통한 데이터의 신뢰적인 전송 (오늘날 TCP의 일부분으로 남겨짐)
• 전달 기능 (오늘날 IP가 수행함)

패킷 음성 같은 애플리케이션을 위한 비신뢰적이고 흐름 제어가 없는 종단 간의 전송 서비스의 중요성에 대한 인식과 결합하여
TCP에 대한 초기 실험은 TCP에서 IP를 분리하도록 했고, UDP 프로토콜을 개발하였다.

TCP, UDP, IP 같은 주요 인터넷 프로토콜은 1970년대 후반에 그 개념이 자리 잡았다.

ALOHA 프로토콜[Abramson 1970]은 지리상 분산된 사용자를 하나의 방송통신매체(라디오 주파수)를 공유하게 하는
최초의 다중 접속(multiple access) 프로토콜이다.

다중 접속 프로토콜에 대한 에이브럼슨의 연구는
유선 기반 공유 브로드캐스트 네트워크를 위한 이더넷 프로토콜[Metcalfe 1976] 개발에서 멧칼프(Metcalfe)와 보그스(Boggs)에 의해 발전되었다.

즉, PC 혁명과 네트워크 폭발이 있기 훨씬 전인 25년 전, 이들은 오늘날의 PC LAN의 기초를 닦고 있었다.

• 1970년대 말까지 약 200개의 호스트가 ARPAnet에 연결되었다.
• 1980년대 말까지 공중 인터넷(네트워크 연합)에 연결된 호스트 수는 십만 개에 이르렀다.

이처럼 1980년대는 거대한 성장 시대였는데, 이러한 성장의 주요인은 대학들을 연결하는 컴퓨터 네트워크를 만드는 여러 노력이었다.

• CSNET(Computer Science Network) : ARPAnet에 접속하지 않고 대학 연구자들을 연결하기 위해 만들어졌다.
• 1986년, NSFNET(National Science Foundation Network)이 NSF이 지원하는 슈퍼컴퓨터센터에 접속 가능하도록 만들어졌다.
• 56 kbps의 초기 백본으로 시작하여 NSFNET의 백본은 1980년대 말에 1.5 Mbps로 동작하게 되었으며, 지역 네트워크를 연결하는 주요 백본이 되었다.

ARPAnet 커뮤니티에서 오늘날 인터넷 구조의 많은 구성요소가 등장했다.

• 1983년 1월 1일, APRAnet의 새로운 표준 호스트 프로토콜인 TCP/IP가 공식 설치되었다. (NCP 프로토콜을 대체)
• NCP에서 TCP/IP로의 전환[RFC 801]은 플래그 데이(flag day) 형태의 사건이었다. 즉, 모든 호스트는 같은 날 동시에 TCP로 전환해야 했다!

1980년대 후반에 호스트 기반의 혼잡 제어를 구축하기 위해 TCP에 중요한 확장이 이루어졌다. [Jacobson 1988]

• 도메인 네임 시스템(domain name system, DNS)의 개발 [RFC 1034]
• 이는 도메인(사람이 읽을 수 있는 인터넷 이름, e.g., jw.edu, euna.com)과 32비트 IP 주소 간의 매핑에 사용된다.

1980년대 초 프랑스에서는 데이터 네트워킹을 모든 가정으로 보급하려는 미니텔(Minitel) 프로젝트를 시작했다.

• 공중 패킷 교환 네트워크 (가상 회선 방식을 사용하는 X.25 프로토콜 스택에 기반을 둠)
• 미니텔 서버와 내장형 저속 모뎀을 포함하는 값싼 터미널로 구성되었다.
• 1984년, 프랑스 정부가 원하는 모든 가정에 무상으로 미니텔 단말기를 제공하고 큰 성공을 거두었다.
• 미니텔 사이트는 전화번호 사이트 같은 무료 사이트와 사용자가 사용량에 따라 요금을 받는 사설 사이트를 포함했다.

1990년대는 인터넷의 지속 발전화 상업화를 상징하는 두 사건으로 대변된다.

1. 인터넷이 원조인 ARPAnet이 더 이상 존재하지 않게 되었다. (1991년에 NSFNET 상업화 제한을 풀었음)
2. 월드와이드웹(World Wide Web, WWW)이 출현하였다.

웹은 검색, 인터넷 상거래, 소셜 네트워크 등을 포함하는 수백 가지의 새 애플리케이션을 만들고 보급하는 플랫폼으로 등장했다.

• 1989~1991년, 팀 버너스 리(Tim Berners-Lee)가 CERN에서 처음으로 만들었다. [Berners-Lee 1989]
• 웹의 네 가지 주요소(HTML, HTTP, 웹 서버, 브라우저)의 초기 버전을 개발하였다.
• 이는 1940년대의 바내바르 부시(Vannevar Bush)와 1960년대 이후의 테드 넬슨(Ted Nelson)이 개발한
  하이퍼텍스트에 관한 초기 연구의 아이디어를 바탕으로 하였다.
• 1993년 말에 약 200개의 웹 서버가 동작 중이었다.

이 시기, 여러 연구자가 GUI 인터페이스형 웹 브라우저를 개발하고 있었으며,
크고 작은 회사가 웹 서버를 운영했고 웹을 통한 상거래를 시작했다.

1990년대 후반은 인터넷의 큰 성장과 혁신의 시대이다.

세기가 끝나는 시점에서 인터넷은 다음 4개의 킬러 애플리케이션을 포함해서 수백 개의 인기 있는 애플리케이션을 지원하게 된다.

• 첨부물과 웹 접속 전자메일을 포함하는 전자메일
• 웹 브라우징과 인터넷 상거래를 포함하는 웹
• 대화상대 목록을 가진 인스턴트 메시징
• 냅스터(Napster)가 개척한 P2P를 통한 MP3 파일 공유

21세기 첫 20년 동안에 인터넷에 연결된 스마트폰과 함께 인터넷보다 사회를 더 변화시킨 기술은 없었다.

그리고 컴퓨터 네트워킹에서의 혁신은 빠른 속도로 계속되어 있다.

그러나 다음의 개발들은 특별한 관심을 끌고 있다.

• 가정에 광대역 인터넷 접속의 공격적인 구축을 목격하고 있다.
  (케이블 모뎀과 DSL뿐만 아니라 그리고 이제는 5G 무선 서비스 포함)

• 고속 무선 인터넷 접속의 빠른 보급
  • 이를 통해 네트워크에 지속적으로 접속할 수 있을 뿐만 아니라, 엘프(Yelp), 틴더(Tinder), 와즈(Waz) 같은
    새로운 위치 기반 애플리케이션이 가능해졌다.
  • 인터넷에 연결되는 무선 장치 수는 2011년에 유선 장치의 수를 초과하였다.

• 페이스북, 인스타그램, 트위터 등 온라인 소셜 네트워크는 인터넷상에 거대한 사람들의 네트워크를 생성했다.
  • API를 통해 온라인 소셜 네트워크는 모바일 결제를 포함하는 새로운 네트워크 애플리케이션과 분산 게임용 플랫폼을 생성한다.

• 1.3.3절에서 논의한 바와 같이 구글와 마이크로스프트 같은 온라인 서비스 제공자는 자신의 커다란 사설 네트워크를 구축하였다.
  • 이는 전 세계적으로 분산된 자신들의 데이터 센터를 연결할 뿐만 아니라
    하위 계층 ISP와 직접 연결(peering)함으로써 가능한 한 많은 인터넷을 우회하는 데 사용된다.
  • 그 결과 구글의 데이터 센터가 마치 사용자의 컴퓨터 내에서 동작하는 것처럼, 구글은 거의 즉각적으로 검색 결과와 전자메일 접속을 제공한다.

• 클라우드 회사는 애플리케이션에 확장 가능한 컴퓨팅과 저장 환경을 제공할 뿐만 아니라, 고성능 사설 네트워크 접속도 제공한다.
  • 많은 인터넷 상거래 회사는 ‘클라우드’에서 자신의 애플리케이션을 수행하고 있다. (아마존의 EC2, 마이크로소프트의 Azure, 알리바바 클라우드)
  • 많은 회사와 대학도 그들의 인터넷 애플리케이션(e.g., 전자메일과 웹 호스팅)을 클라우드로 이동했다.

1.2절의 종단 시스템을 연결하는 패킷 스위치와 링크의 그물망(mesh)에 대하여 살펴보도록 하자.

아래 그림에서의 굵은 선들은 네트워크 코어를 나타낸 것이다.

링크와 스위치의 네트워크를 통해 데이터를 이동시키는 두 가지 기본 방식

1. 패킷 교환(packet switching) : 보장되지 않는 (e.g., 인터넷)
2. 회선 교환(circuit switching) : 자원을 예약 → 보장된

종단 시스템들은 서로 메시지(message)를 교환한다. (출발지 종단 시스템에서 목적지 종단 시스템으로 메시지를 보냄)

1. 송신 시스템은 메시지를 패킷(packet)이라고 하는 작은 데이터 덩어리로 분할한다.
2. 각 패킷은 통신 링크(communication link)와 패킷 스위치(packet switch)를 거치게 된다.
   • 패킷 스위치에는 라우터(router)와 링크 계층 스위치(link-layer switch)의 두 가지 유형이 존재한다.
3. 패킷은 링크의 최대 전송률과 같은 속도로 각각의 통신 링크에서 전송된다.
   • 출발지 종단 시스템 혹은 패킷 스위치가 R bps(bits per second)의 속도로 링크에서 L 비트의 패킷을 송신한다면,
     그 패킷을 전송하는 데 걸리는 시간은 L/R 초

💡 스위치가 패킷의 첫 비트를 출력 링크로 전송하기 전에 전체 패킷을 받아야 한다.

저장-후-전달 전송 방식은 대부분의 패킷 스위치가 이용하는 방식이다.

위는 하나의 라우터로 연결되고 2개의 종단 시스템으로 구성된 매우 간단한 네트워크 예시이다.

• 출발지는 목적지로 전송할 3개의 패킷(1, 2, 3)을 가지고 있으며, 각각의 패킷은 L 비트로 구성되어 있다.
• 출발지는 링크에서 L 비트의 패킷을 R bps(bits per second)의 속도로 송신하고 있다.

그림에서 보이는 것처럼 출발지는 패킷 1의 일부분을 전송했고, 그 부분이 라우터에 도착해있는 상황을 생각해보자.

이때 라우터는 저장-후-전달 방식을 채택하고 있기 때문에 수신한 비트를 전송할 수 없다. 그 대신, 아래의 과정이 진행된다.

1. 패킷의 비트를 먼저 저장(buffer, 즉 ‘store’)한다.
2. 라우터가 패킷의 모든 비트를 수신하였다면 그제서야 출력 링크로 그 패킷을 전송(transmit, 즉 ‘forward’)하기 시작한다.

1-1. 출발지에서 패킷 1을 송신하기 시작해서 패킷 1의 전체를 목적지에서 수신할 때까지의 경과 시간을 계산해보자.

여기서 전파 지연(propagation delay)은 무시하도록 하자. 이는 비트가 빛의 속도에 가까운 속도로 통신선을 거쳐가는 데에 걸리는 시간을 말한다.
→ 1.4절에서 논의

• 0 초 : 출발지가 패킷 1을 전송하기 시작
• L/R 초
  • 출발지는 패킷 1의 전체 데이터를 전송 완료했으며, 전체가 라우터에 수신되고 저장되었다. (전파 지연이 없기 때문)
  • 라우터가 전체 패킷을 수신했기 때문에 라우터는 목적지를 향해 그 패킷을 출력 링크로 전송하기 시작한다.
• 2L/R 초 : 라우터는 전체 패킷을 전송했으며, 목적지는 패킷 1 전체를 수신 완료한다. (전파 지연이 없기 때문)

따라서 저장-후-전달 전송 방식을 채택한다면 전체 지연은 2L/R이며,
이 방식 없이 스위치에 비트가 도착하자마자 곧바로 전달을 하게 된다면 전체 지연은 L/R이 된다.

하지만 라우터는 전달하기에 앞서 전체 패킷을 수신, 저장, 처리할 필요가 있다. (이것도 1.4절에서 자세히 논의한다.)

1-2. 출발지가 패킷 1을 송신하기 시작한 순간부터 목적지 노드가 3개의 모든 패킷(1, 2, 3)을 수신할 때까지 경과된 전체 시간을 계산해보자.

• 0 초 : 출발지가 패킷 1을 전송하기 시작
• L/R 초
  • 라우터는 패킷 1을 수신 완료, 이를 전송하기 시작
  • 출발지는 패킷 2를 전송하기 시작
• 2L/R 초
  • 라우터는 패킷 2를 수신 완료, 이를 전송하기 시작
  • 목적지는 패킷 1 전체를 수신 완료
  • 출발지는 패킷 3을 전송하기 시작
• 3L/R 초
  • 라우터는 패킷 3를 수신 완료, 이를 전송하기 시작
  • 목적지는 패킷 2 전체를 수신 완료
• 4L/R 초 : 목적지는 패킷 3 전체를 수신 완료

따라서 저장-후-전달 전송 방식을 채택한다면 목적지는 4L/R 초에 3개의 모든 패킷을 수신하게 된다.

2. 출발지로부터 목적지 노드까지 N개의 링크로 구성되고 각각은 전송률이 R인 경로를 통해 하나의 패킷을 전송하는 경우를 생각해보자.

즉, 출발지와 목적지 사이에 N-1개의 라우터가 존재한다는 것이다.

실제로 라우터는 보통 여러 개의 링크를 갖는데, 그 이유는 라우터의 기능이 입력되는 패킷을 출력 링크로 교환하는 것이기 때문이다.

1-1, 1-2와 같은 논리를 적용한다면 종단 간 지연은 다음과 같음을 알 수 있다.

• 각 패킷 스위치는 접속된 여러 링크를 가지고 있으며, 패킷 스위치는 각 링크에 대해 출력 버퍼를 가지고 있다.
• 출력 버퍼(output buffer)는 출력 큐(output queue)로도 불리며, 그 링크로 송신하려고 하는 패킷을 저장하고 있다.
  이는 패킷 교환에서 중요한 역할을 한다.

패킷이 겪는 지연은 앞에서 보았던 저장-후-전달 지연만 존재하는 것이 아니다.

도착하는 패킷은 한 링크로 전송되어야 한다. 하지만 만약 그 링크가 다른 패킷을 전송하고 있는 중이라면 어떻게 해야 하는가?

→ 도착하는 패킷은 출력 버퍼에서 대기해야 한다. = 큐잉 지연

• 큐잉 지연은 가변적이며, 네트워크의 혼잡 정도에 따른다.
• 버퍼 공간의 크기는 유한하기 때문에 패킷 손실(packet loss)이 발생할 수 있다.
• 즉, 버퍼가 전송을 위해 대기 중인 다른 패킷들로 꽉 차 있는 경우라면 도착하는 패킷 또는 큐에 대기 중인 패킷을 폐기(drop)하는 것이다.

아래의 예시를 보자.

여기서 라우터는 수신한 패킷을 15 Mbps의 링크로 전달하고 있다.

만약 짧은 기간 동안 라우터에 도착하는 패킷의 전송률이 15 Mbps를 초과하게 된다면, 링크의 출력 버퍼에 패킷들이 큐잉될 것이다.

라우터는 접속된 통신 링크 중 하나로 도착하는 패킷을 받아, 접속된 통신 링크 중 다른 링크로 그 패킷을 전달한다.

그렇다면 라우터는 그 패킷을 어느 링크로 전달해야 하는지를 어떻게 결정할까?

패킷 전달은 실제 여러 유형의 컴퓨터 네트워크에서 다른 방식으로 실행되는데, 여기서는 라우팅이 인터넷에서 어떻게 실행되는지를 간단히 설명한다.

• 인터넷에서 모든 종단 시스템은 IP 주소를 가지며, 이 주소는 계층적 구조를 갖는다.
• 출발지 종단 시스템이 목적이 종단 시스템으로 패킷을 보내고자 할 때 출발지는 패킷의 헤더에 목적지의 IP 주소를 포함한다.

각 라우터는 목적지 주소 또는 목적지 주소의 일부를 라우터의 출력 링크로 매핑하는 포워딩 테이블을 가지고 있다.

따라서 라우터가 수신한 패킷을 어느 링크로 전달해야 하는지를 결정하는 과정은 다음과 같다.

1. 패킷이 라우터에 도착한다.
2. 라우터는 패킷의 IP 주소를 조사한다.
3. 해당 목적지 주소를 이용하여 포워딩 테이블을 검색한다.
4. 그 패킷을 출력 링크로 보낸다.

그렇다면 포워딩 테이블은 어떻게 설정되는 것일까? (5장에서 자세히 논의)

인터넷은 자동으로 포워딩 테이블을 설정하는 데 이용되는 여러 특별한 라우팅 프로토콜을 가지고 있다.

e.g., 각 라우터로부터 각 목적지까지 최단 경로를 결정 → 라우터에 포워팅 테이블을 설정하는 데에는 이 최단 경로 결과를 이용한다.

• 회선 교환 네트워크에서는 종단 시스템 간에 통신을 제공하기 위해
  경로상에서 필요한 자원(버퍼, 링크 전송률)은 통신 세션(session) 동안에 확보 또는 예약(reserve)된다. (↔︎ 패킷 교환 네트워크)
• 세션 메시지는 온디맨드(on-demand) 방식으로 자원을 요청하여 사용한다.
• 따라서 통신 링크에 대한 접속을 위해 큐에서 대기해야 할 수도 있다.

• 연결 = 회선(circuit) : 송신자와 수신자 간의 경로에 있는 스위치들이 해당 연결 상태를 유지해야 한다.

1. 송신자가 정보를 보내기 전, 네트워크는 송신자와 수신자 간의 연결을 설정해야 한다.
2. 네트워크가 회선을 설정할 때, 그 연결이 이루어지는 동안 네트워크 링크에 일정한 전송률을 예약한다.
3. 주어진 전송률이 송신자-수신자 연결을 위해 예약되기 때문에, 송신자는 수신자에게 보장된(guaranteed) 일정 전송률로 데이터를 보낼 수 있다.

아래는 4개의 스위치와 4개의 링크로 구성된 회선 교환 네트워크를 나타낸 그림이다.

이들 각 링크는 4개의 회선을 가지므로 각 링크는 4개의 동시 연결을 지원할 수 있다.

만약 두 호스트가 통신하고 싶을 때, 네트워크는 두 호스트 사이에 지정된 종단 간 연결을 설정한다.

즉, 호스트 A가 호스트 B와 통신하기 위해서 네트워크는 먼저 A의 링크와 B의 링크 각각에서 한 회선씩을 예약한다.
(위 그림에서는 링크(0, 0)의 두 번째 회선, 링크(1, 1)의 두 번째 회선)

각 링크에 대하여 연결이 지속되는 동안 해당 연결은 링크 전체 전송 용량의 1/4를 얻는다. (각 링크는 4개의 회선을 가지고 있기 때문)

반대로, 한 호스트가 인터넷 같은 패킷 교환 네트워크를 통해 다른 호스트로 패킷을 보내고자 하는 경우에는 어떤 일이 발생할까?

회선 교환과 마찬가지로 패킷은 일련의 통신 링크를 통해 전송된다.

하지만 회선 교환과는 다르게, 패킷 교환은 링크 자원을 예약하지 않고 네트워크로 보내진다.

💡 패킷 교환 네트워크는 일정한 시간 내에 데이터를 전달하는 것을 보장하지 않는다.

링크 내 한 회선이 구현되는 방법

1. 주파수 분할 다중화(Frequency-Division Multiplexing, FDM) : 각 회선은 지속적으로 대역폭의 일부를 얻는다.
2. 시분할 다중화(Time-Division Multiplexing, TDM) : 각 회선은 주기적으로(짧은 시간 즉, 슬롯 동안) 전체 대역폭을 얻는다.

• 링크를 통해 설정된 연결은 그 링크의 주파수 스펙트럼을 공유한다.
• 그 링크는 연결되는 동안 각 연결에 대해 주파수 대역을 고정 제공한다. = 대역폭(bandwidth)

• TDM 링크는 시간을 일정 주기의 프레임으로 구분하고, 각 프레임은 고정된 수의 시간 슬롯으로 나뉜다.
• 네트워크가 링크를 통해 하나의 연결을 설정할 때, 네트워크는 모든 프레임에서 시간 슬롯 1개를 그 연결에 할당한다.
• 전송률 : 한 슬롯 안의 비트 수 × 프레임 전송률

[ 패킷 교환 옹호자 ]

• 주장
  1. 패킷 교환이 회선 교환보다 전송 용량의 공유에서 더 효율적이다.
  2. 패킷 교환이 회선 교환보다 더 간단하고 효율적이며, 구현 비용이 적다.
• 근거
  • 회선 교환에서 통신을 위해서는 자원이 항상 각각의 사용자에게 예약되어야만 한다.
  • 할당된 회선이 비활용 기간(silent period)에는 자원을 점유한 채로 놀게 되기 때문에 자원 이용률이 감소한다.
  • 즉, 회선 교환에서는 사용되지 않는 네트워크 자원(연결 경로상의 링크 주파수 대역이나 슬롯)은 다른 진행 중인 연결이 대신해서 사용할 수 없기 때문에
    패킷 교환이 더 효율적이다.

[ 패킷 교환 반대자 ]

• 주장 : 패킷 교환은 실시간 서비스에는 적당하지 않다.
• 근거 : 주로 큐잉 지연에서 발생하는 종단 간의 지연 (불규칙적이고 예측할 수 없음)

과연 패킷 교환 반대자의 주장은 옳을까?

이를 확인해보기 위해서 간단한 예 두 가지를 살펴보자.

1. 사용자가 1 Mbps 링크를 공유한다고 가정하고, 각 사용자들은 활동 시간과 비활동 시간을 반복한다고 하자.
사용자는 전체 시간에서 10%만 활동하며 나머지 90% 시간에는 활동하지 않는다.

• 활동 시간 : 100 kbps의 일정 속도로 데이터를 생산할 때
• 비활동 시간 : 데이터를 생산하지 않을 때

✅ 회선 교환의 경우, 100 kbps가 항상 각각의 사용자에게 예약되어야 한다.
TDM 회선 교환을 예시로, 초 프레임이 100 ms마다 10개 시간 슬롯으로 나뉜다고 한다면 각 사용자에게는 한 프레임에 한 번의 시간 슬롯이 할당된다.
따라서 회선 교환 링크는 동시에 10명(= 1 Mbps / 100 kbps)만 지원할 수 있다.

✅ 패킷 교환의 경우, 한 특정 사용자가 활동을 하고 있을 확률은 10%이다.
만약 10명 이하의 동시 사용자가 있다면 그 확률은 99.96%, 데이터의 통합 도착률은 1 Mbps(링크의 출력률)보다 작거나 같다.
따라서 10명 이상의 동시 사용자가 있다면 패킷의 통합 도착률이 링크의 출력 용량을 초과하기 때문에 출력 큐가 커지기 시작한다.
(이 큐는 통합 입력률이 1 Mbps 이하로 떨어질 때까지 커질 것이고, 이후에는 큐 길이가 줄어들기 시작할 것)

10명 이상의 동시 사용자가 있을 확률은 0.04%로 굉장히 작으므로,
패킷 교환은 거의 항상 회선 교환과 대등한 지연 성능을 가지면서도 거의 3배 이상의 사용자 수를 허용한다.

1. 사용자가 1 Mbps 링크를 공유한다고 가정하고, 각 사용자들은 활동 시간과 비활동 시간을 반복한다고 하자.
사용자는 전체 시간에서 10%만 활동하며 나머지 90% 시간에는 활동하지 않는다.

• 활동 시간 : 100 kbps의 일정 속도로 데이터를 생산할 때
• 비활동 시간 : 데이터를 생산하지 않을 때

✅ 회선 교환의 경우를 먼저 보자.
TDM 회선 교환을 예시로, 한 프레임은 10개 슬롯으로 구성되고 각 슬롯은 1,000비트로 구성되었다면
사용자는 데이터 전송을 위해 한 프레임당 1개의 시간 슬롯만 사용할 수 있다. 반면에 각 프레임에 남겨진 9개의 시간 슬롯은 쉬는 상태가 된다.
따라서 사용자의 데이터 100만 비트를 모두 전송하려면 10초가 걸린다.

✅ 패킷 교환의 경우,
패킷을 생성하는 다른 사용자가 없기 때문에 다중화가 요구되지 않고, 사용자는 1 Mbps의 링크가 가득 찰 때까지 패킷을 계속 보낼 수 있다.
따라서 사용자의 데이터 100만 비트는 1초 만에 모두 전송된다.

앞의 두 가지 예에서 명확하게 볼 수 있듯, 패킷 교환이 회선 교환보다 성능이 우수하다.

따라서 오늘날의 전기통신 네트워크의 추세는 패킷 교환으로 전환되고 있다.

링크 전송률을 공유하는 두 방식의 가장 큰 차이점은 아래와 같이 정리할 수 있다.

• 회선 교환 방식 : 요구에 관계없이 미리 전송 링크의 사용을 할당한다.
• 패킷 교환 방식 : 요구할 때만 링크의 사용을 할당한다.

• ISP(Internet Service Provider) : 패킷 스위치와 통신 링크로 이루어진 네트워크
  1. 종단 시스템에게 다양한 네트워크 접속을 제공한다. (e.g., 가정용 초고속 접속, 고속 LAN 접속, 이동 무선 접속 등)
  2. CP(content provider)에게 인터넷 접속을 제공 → 웹 사이트나 비디오 서버를 인터넷에 직접 연결할 수 있게 된다.
• 종단 시스템(PC, 스마트폰, 웹 서버 등)은 접속 ISP를 통해 인터넷에 연결된다.
• 접속 ISP는 다양한 접속 기술(DSL, 케이블, FTTH, 와이파이, 셀룰러(이동 통신) 등)을 이용하여 유선 또는 무선 연결을 제공한다.

접속 ISP는 텔코 혹은 케이블 회사일 필요가 없다.
e.g., 대학교 - 학생, 직원, 교수에게 인터넷 접속을 제공, 회사 - 직원에게 인터넷 접속을 제공

그러나 종단 사용자들과 콘텐츠 제공자들을 모두 접속 ISP로 연결하는 것은 말도 안 된다.

이를 위해서는 접속 ISP들이 서로 연결되어야만 하기 때문에 네트워크의 네트워크(network of network)가 탄생하게 되었다.

💡 목표 : 모든 종단 시스템이 서로에게 패킷을 보낼 수 있도록 접속 ISP를 연결하는 것

가장 간단한 방법은 각 접속 ISP를 직접 서로 다른 ISP와 연결하는 것이다.

하지만 각 접속 ISP가 전 세계적으로 다른 접속 ISP와 수십만 개의 개별적인 통신 링크를 유지해야 하기 때문에,
이런 그물망 설계는 접속 ISP에게 너무 많은 비용을 발생시킨다.

오늘날의 인터넷 네트워크 구조를 이해하기 위해 점진적으로 일련의 네트워크 구조를 만들어보자.

모든 접속 ISP를 하나의 글로벌 통과(transit) ISP와 연결한다.

• 글로벌 통과 ISP : 라우터 + 전 세계에 이르고, 적어도 수십만 개의 접속 ISP와 가까운 곳에 있는 라우터를 갖는 통신 링크의 네트워크
• 글로벌 ISP가 이러한 확장된 네트워크를 구축하는 데는 매우 많은 비용이 든다.
• 글로벌 ISP는 이익을 얻기 위해 각각의 접속 ISP에 연결을 위한 과금을 부과한다.
  • 접속 ISP는 고객(customer)
  • 글로벌 ISP는 제공자(provider)

어느 회사가 수익을 내는 글로벌 ISP를 구축하고 운영한다면, 다른 회사가 자신의 글로벌 ISP를 구축하여 경쟁하는 것은 자연스러운 일이다.

이것이 네트워크 구조 2로 진화한다.

수십만 개의 접속 ISP와 다중의 글로벌 ISP

• 2계층구조
  • 상위층 : 글로벌 ISP 서비스 제공자가 존재
  • 하위층 : 접속 ISP가 존재
• 글로벌 ISP들은 서로 연결해야만 한다.
• 서로 연결되지 않는다면 하나의 글로벌 ISP와 연결된 접속 ISP는 다른 글로벌 통과 서비스 제공자에 연결된 접속 ISP와 통신할 수 없다.

현실적으로 전 세계의 모든 도시에 존재하는 ISP는 없다.

대신, 어느 주어진 지역에서 그 지역에 있는 접속 ISP들이 연결하는 지역(regional) ISP가 존재하며, 각 지역 ISP는 1계층(tier-1) ISP들과 연결된다.
(실제로 존재하는 1계층 ISP는 전 세계적으로 모든 도시에 존재하지는 않는다.)

다중계층구조(접속 ISP, 지역 ISP, 1계층 ISP) → 오늘날의 인터넷과 대략적으로 유사

여러 경쟁적인 1계층 ISP들이 존재하며, 한 지역에 여러 경쟁적인 지역 ISP들이 존재할 수 있다.

더 복잡한 경우, 작은 지역 ISP들이 연결하는 좀 더 큰 지역 ISP들이 있을 수 있다.

이런 계층구조에서의 과금은 크게 다음과 같이 진행된다.

고객 ISP는 글로벌 인터넷 연결성(interconnectivity)을 얻기 위해 서비스 제공 ISP에게 요금을 지불하기 때문에
"각 레벨에는 고객-제공자 관계가 존재한다"고 할 수 있다.

1. 각각의 접속 ISP는 자신이 연결하는 지역 ISP에게 요금을 지불한다.
2. 각 지역 ISP는 자신이 연결하는 1계층 ISP에게 요금을 지불한다.
3. 1계층 ISP는 계층구조의 최상위에 있기 때문에 아무에게도 요금을 지불하지 않는다.

다중계층구조(접속 ISP, 지역 ISP, 1계층 ISP) + PoP + 멀티홈 + 피어링 + IXP

오늘날의 인터넷과 좀 더 유사한 네트워크를 구축하기 위해서는 네트워크 구조 3에 아래 4가지 항목들을 포함해야 한다.

• PoP(Points of Presence)
  • 단지 제공자의 네트워크 내에 있는(같은 위치에 존재하는) 하나 혹은 그 이상의 라우터 그룹
  • 최하위(접속 ISP) 계층을 제외한 모든 계층에 존재하며, 고객 ISP가 제공자 ISP에 연결될 수 있다.
  • 고객 네트워크가 제공자의 PoP에 연결되기 위해,
    고객은 자신의 라우터 중 하나를 PoP에 있는 라우터에 직접 연결하도록 고속 링크를 제3자(third-party) 통신 서비스 제공자로부터 임대할 수 있다.
• 멀티홈(multi-homing)
  • 둘 혹은 그 이상의 제공자 ISP에 연결하는 것
  • e.g., 한 접속 ISP가 2개의 ISP에 연결, 2개의 지역 ISP와 함께 하나의 1계층 ISP에 연결
  • 1계층 ISP를 제외한 모든 ISP는 멀티홈을 선택할 수 있다.
  • 한 ISP가 멀티홈을 하면 서비스 제공자 중 하나가 연결되지 않더라도 인터넷으로 패킷을 계속 송수신할 수 있게 된다.
• 피어링(peering)
  • 고객 ISP가 서비스 제공 ISP에게 지불하는 요금을 줄이기 위해 인터넷 계층구조의 같은 계층에 있는 가까운 ISP들은 피어링할 수 있다.
    (두 ISP가 피어링하면 일반적으로 서로 요금을 지불하지 않음)
  • 즉, 이들 간에 송수신되는 모든 트래픽을 상위 계층 ISP를 통하지 않고 직접 송수신할 수 있도록 자신들의 네트워크를 서로 직접 연결하는 것이다.
  • 1계층 ISP들도 서로 피어링할 수 있다.
• IXP(Internet Exchange Point)
  • 다중의 ISP들이 서로 피어링할 수 있는 만남의 장소
  • 일반적으로 교환기를 갖춘 독자적인 빌딩에 존재한다.

다중계층구조(접속 ISP, 지역 ISP, 1계층 ISP) + PoP + 멀티홈 + 피어링 + IXP + 콘텐츠 제공 네트워크

이는 2012년의 인터넷을 기술하며, 구글이 이러한 콘텐츠 제공자 네트워크 주도하는 한 예이다.

• 구글 데이터 센터는 모두 구글의 사설 TCP/IP 네트워크를 통해 연결되어 있으며, 이 네트워크는 전 세계를 연결하며 공중 인터넷과는 분리되어 있다.
• 구글 사설 네트워크는 구글 서버로 오가는 트래픽만 전달한다.
• 즉, 하위 계층 ISP들과 피어링을 함으로써(그들과 직접 연결하거나 IXP에서 그들과 연결함으로써) 인터넷의 상위 계층을 ‘우회(bypass)’하고 있다.
  (아래 그림 참고)

• 많은 접속 ISP는 여전히 1계층 네트워크를 통해서만 도달할 수 있기 때문에
  구글 네트워크도 1계층 ISP들과 연결하고 그들과 교환하는 트래픽에 대해 이 ISP들에게 요금을 지불한다.
• 콘텐츠 제공자들이 자신의 네트워크를 구축함으로써 얻는 이점
  • 상위 계층 ISP들에게 지불하는 요금을 줄일 수 있다.
  • 최종 사용자들에게 자신들의 서비스가 궁극적으로 어떻게 전달되는지에 대한 더 많은 통제권을 가질 수 있다.

최종 정리하자면 다음과 같다.

💡 오늘날의 인터넷(네트워크의 네트워크)는 12개 정도의 1계층 ISP들과 수십만 개의 하위 계층 ISP들로 구성되어 있다.

• 하위 계층 ISP들은 상위 계층 ISP들과 연결하고, 상위 계층 ISP들은 서로 연결한다.
• 사용자와 콘텐츠 제공자는 하위 계층 ISP 고객이고, 하위 계층 ISP들은 상위 계층 ISP들이 고객이다.
• 최근에 주요 콘텐츠 제공자도 자신의 네트워크를 구축했고 가능한 곳에서 하위 계층 ISP들과 직접 연결한다.

패킷은 한 호스트(출발지)에서 시작하고 일련의 라우터들을 통과하며 다른 호스트(목적지)에 도달한다.

패킷이 경로를 따라 한 노드에서 다음 노드로 전달될 때 패킷은 경로상의 각 노드에서 다양한 지연을 겪게 되며,
이들은 쌓여서 전체 노드 지연(total nodal delay)을 일으킨다.

• 노드 처리 지연(nodal processing delay)
• 큐잉 지연(queuing delay)
• 전송 지연(transmission delay)
• 전파 지연(propagation delay)

아래의 그림을 보며 큰 그림을 그려보자. 이는 라우터 A에서의 노드 지연을 나타낸 것이다.

출발지와 목적지 사이 종단 간 경로의 일부로서, 한 패킷이 업스트림 노드로부터 라우터 A를 통해 라우터 B로 보내진다.

• 업스트림(upstream) : 클라이언트에서 서버로 전송되는 데이터의 흐름
• 다운스트림(downstream) : 서버에서 클라이언트로 전송되는 데이터의 흐름, 일반적으로 다운스트림 트래픽은 업스트림 트래픽보다 더 많은 볼륨이 있다.

라우터 A는 라우터 B에 이르는 하나의 출력(outgoing) 링크를 가지며, 이 링크 앞에 큐(queue, 버퍼(buffer))가 존재한다.

1. 패킷이 업스트림 노드로부터 라우터 A에 도착한다.
2. 라우터 A는 그 패킷에 대한 적당한 출력 링크를 결정하기 위해 패킷 헤더를 조사한다.
3. 라우터 A는 선택된 링크로 그 패킷을 보낸다. (그림에서 선택된 링크 = 라우터 B에 이르는 링크)

만약 라우터 B에 이르는 링크에 현재 전송되는 다른 패킷이 존재하거나, 큐에 자신보다 앞선 다른 패킷들이 존재한다면 어떻게 되는가?

새로 도착하는 패킷은 그 링크를 이용하기 위해 큐에 들어갈 것이다.

이 모든 과정에서 여러 지연이 발생한다.

💡 패킷 헤더를 조사하고 그 패킷을 어디로 보낼지 결정하는 시간

• 라우터 A로 패킷의 비트를 전송할 때 업스트림 노드에서 발생하는 패킷의 비트 레벨 오류를 조사하는 데 필요한 시간과 같은 요소를 포함할 수도 있다.
• 라우터는 이 노드 처리 후, 그 패킷을 라우터 B에 이르는 링크에 앞선 큐에 보낸다.
• 고속 라우터의 처리 지연은 일반적으로 수 마이크로초이다.

💡 패킷이 큐에서 링크로 전송되기를 기다리는 시간

• 특정 패킷의 큐잉 지연 길이는 큐에 저장되어 링크로 전송되기를 기다리는, 앞서 도착한 다른 패킷의 수에 의해 결정된다.
• 주어진 패킷의 지연은 패킷마다 상당히 다르다.
  • 큐가 비어있고 다른 패킷이 전송 중인 상태가 아니라면 패킷의 큐잉 지연 → 0
  • 트래픽이 많고 다른 많은 패킷이 전송 대기 중이라면 패킷의 큐잉 지연 → 매우 길어진다.
• 수 마이크로초 ~ 수 밀리초

💡 패킷의 모든 비트를 링크로 밀어내는 데(또는 전송하는 데) 필요한 시간

패킷이 선입선출(FIFO) 방식으로 전송된다고 가정해보자. (앞서 도착한 다른 모든 패킷이 전송된 다음에 전송)

패킷의 길이는 L 비트, 라우터 A에서 라우터 B까지 링크의 전송률은 R bps라고 해보자. (R는 라우터 B로 가는 링크의 전송률에 의해 결정됨)

이때 전송 지연은 L/R이다. (수 마이크로초 ~ 수 밀리초)

💡 비트가 라우터 A 상에서의 링크에서 라우터 B까지의 전파에 필요한 시간

• 비트는 링크의 전파 속도로 전파된다.
• 전파 속도는 링크의 물리 매체(광섬유, 꼬임쌍선 등)에 따라 다르며, 범위는 2×(10^8)미터/초 ~ 3×(10^8)미터/초이다.
  → 빛의 속도와 같거나 약간 작다.

라우터 A와 B 사이의 거리를 d, 링크의 전파 속도를 s라고 한다면 전파 지연은 d/s이다. (일반적으로 수 밀리초)

• 라우터가 패킷을 내보내는 데 필요한 시간
• 패킷 길이와 링크 전송률의 함수 → 두 라우터 사이의 거리와는 관계가 없다.

• 비트가 한 라우터에서 다음 라우터로 전파되는 데 걸리는 시간
• 두 라우터 사이의 거리에 대한 함수 → 패킷 길이나 링크 전송률과는 관계가 없다.

💡 전체 노드 지연 = 처리 지연 + 큐잉 지연 + 전송 지연 + 전파 지연

각각 지연 요소의 기여도에는 상당한 차이가 존재한다.

• 내부의 두 라우터를 연결하는 링크에서는 2마이크로초 정도 → 무시 가능
• 정지 위성 링크로 연결된 두 라우터의 경우 수백 밀리초 → 전체 노드 지연의 주요 요소가 된다.

• LAN처럼 10 Mbps 이상의 전송률인 경우 → 무시 가능
• 저속 다이얼업 모뎀 링크에서 보내지는 인터넷 패킷은 수백 밀리초에 이를 수 있다.

• 이는 보통 전체 노드 지연에서는 무시될 수 있다.
• 하지만 라우터가 패킷을 전달할 수 있는 최대율(최대 속도)에는 상당한 영향을 준다.

노드 지연(한 라우터에서의 지연)에 대하여 알아보자.

다른 세 가지 지연과 다르게, 큐잉 지연은 패킷마다 다를 수 있다.

e.g., 10개의 패킷이 동시에 비어 있는 큐에 도착한다면?

• 전송된 첫 패킷은 큐잉 지연을 겪지 않는다.
• 마지막으로 전송되는 패킷은 많은 큐잉 지연을 겪게 된다. (다른 9개 패킷이 전송되기를 기다림)

따라서 큐잉 지연의 특성 묘사는 평균 큐잉 지연, 큐잉 지연의 분산, 큐잉 지연이 어느 특정 값을 넘을 확률 같은 통계 측정을 일반적으로 이용한다.

• 트래픽이 큐에 도착하는 비율
• 링크의 전송률
• 도착하는 트래픽의 특성 (트래픽이 주기에 맞춰서 또는 버스트(burst)하게 도착하는가?)

아래의 상황을 가정해보자.

패킷이 큐에 도착하는 평균율 : a 패킷/초
전송률(패킷이 큐에서 밀려나는 비율) : R 비트/초
모든 패킷은 L 비트
큐가 매우 커서 무한대 비트를 저장할 수 있음

이때 트래픽 강도(traffic intensity, 비트가 큐에 도착하는 평균율)은 La/R 비트/초다.
(트래픽 강도는 큐잉 지연의 정도를 측정하는 데에 매우 중요)

✅ La/R > 1이라면 비트가 큐에 도착하는 평균율이 비트가 큐에서 전송되는 비율을 초과한다는 것을 의미한다.

따라서 큐는 끝없이 증가, 큐잉 지연은 무한대에 도달한다. → 트래픽 강도가 1보다 크지 않게 시스템을 설계해야 한다.

✅ La/R ≤ 1인 경우에는 도착 트래픽의 특성이 큐잉 지연에 영향을 미친다.

• 하나의 패킷이 L/R 초마다 주기적으로 도착한다면 모든 패킷은 빈 큐에 도착 → 큐잉 지연은 없을 것이다.
• 패킷이 몰려서(burst) 도착한다면 상당한 평균 큐잉 지연이 발생할 것이다.

일반적으로 패킷의 도착에는 고정된 패턴이 없고, 임의의 시간만큼 떨어져서 도착하게 된다. (random)

아래 그래프는 트래픽 강도에 대한 평균 큐잉 지연의 질적 의존도를 나타낸다.

💡 트래픽 강도가 1에 접근할수록 평균 큐잉 지연이 급속히 증가한다.

• 트래픽 강도가 0에 가까울 경우
  • 패킷 도착이 드물고 간격이 멀어서 다음에 도착하는 패킷이 큐에서 다른 패킷을 발견하는 경우가 없다.
  • 따라서 평균 큐잉 지연은 0에 가까워진다.
• 트래픽 강도가 1에 가까울 경우
  • 패킷 도착이 전송용량을 초과하여 큐가 생성될 것이다.
  • 도착률이 전송률보다 작아질 때 큐의 길이가 줄어든다.

앞에서는 큐가 무한대 패킷을 가질 수 있다고 가정했으나, 실제로는 유한 용량을 가지며 스위치 설계와 비용에 크게 의존한다.

즉, 트래픽 강도가 1에 접근함에 따라 패킷 지연이 무한대가 되진 않으며, 대신 큐가 꽉 차게 된다.

💡 큐가 꽉 차서 패킷을 저장할 수 없는 경우에 라우터는 그 패킷을 버린다(drop).

• 손실 패킷의 비율은 트래픽 강도가 클수록 증가한다.
• 모든 데이터가 궁극적으로 목적지까지 전달되었음을 보장하기 위해 손실 패킷은 종단 간에 재전송될 수 있다.

정리하자면, 노드에서의 성능 측정 요소는 다음의 두 가지이다.

• 지연 정도
• 패킷 손실 확률

출발지에서 목적지까지의 지연에 대하여 알아보기 위해, 다음의 상황을 생각해보자.

출발지 호스트와 목적지 호스트 사이에 N-1개의 라우터가 있다.
네트워크가 혼잡하지 않아 큐잉 지연을 무시할 수 있다.
각 호스트와 출발지 호스트에서의 전송률은 R 비트/초이다.
패킷의 크기는 L 비트이다.

종단 간 지연 = N(처리 지연 + 전송 지연(L/R) + 전파 지연)

이는 1.3절에서 언급한, 처리와 전파 지연을 고려하지 않은 종단 간 지연 식을 일반화한 것이다.

컴퓨터 네트워크에서의 주요한 성능 수단은 다음의 세 가지이다.

• 지연 정도
• 패킷 손실 확률
• 종단 간 처리율(throughput)

컴퓨터 네트워크를 통해 호스트 A에서 호스트 B로 커다란 파일을 전송하는 상황을 생각해보자.

해당 파일은 F 비트로 구성되며, 호스트 B가 파일의 모든 F 비트를 수신하는 데 T초가 걸린다고 한다면,

• 어느 한 순간에서의 순간적인 처리율(instantaneous throughput) = 호스트 B가 파일을 수신하는 비율(비트/초)
• 평균 처리율(average throughtput) = F/T 비트/초

인터넷 전화 같은 애플리케이션의 경우, 낮은 지연과 순간적인 처리율이 지속적으로 어떤 임계값(threshold)을 넘는 것이 바람직하다.

파일 전송을 포함하는 다른 애플리케이션의 경우, 지연은 심각하지 않으나 가능한 한 높은 처리율을 가지는 것이 바람직하다.

서버로부터 클라이언트로의 파일 전송에 대한 처리율을 생각해보기 위해 두 가지 예시를 보자.

그림 a는 2개의 통신 링크와 라우터로 연결된 하나의 서버와 하나의 클라이언트를 나타낸다.
(전체 네트워크로 보내지는 비트는 서버에서 클라이언트로만 보내지는 비트라고 가정)

Rs : 서버와 라우터 간의 링크 속도
Rc : 라우터와 클라이언트 간의 링크 속도

이때 서버-클라이언트 처리율은 얼마인가? (비트는 유체(fluid), 통신 링크는 파이프(pipe)로 생각해보자)

서버는 Rs bps보다 빠른 속도로 링크상으로 비트를 내보낼 수 없고, 라우터는 Rc bps보다 빠른 속도로 비트를 전달할 수 없다.

• Rs < Rc인 경우 : Rs bps
• Rc < Rs인 경우 : Rc bps
  • 라우터는 자신이 수신하는 비트만큼 빠르게 그 비트들을 전달할 수 없다.
  • 클라이언트로의 전송을 위해 기다리는 라우터의 비트들은 계속해서 증가할 것이다.

처리율 = min{Rc, Rs} = 병목 링크(bottleneck link)의 전송률

그림 b는 서버와 클라이언트 간에 N개의 링크를 가진 네트워크를 보여주고 있다.
N개 링크의 전송률 : R1, R2, ... , RN

이때의 서버-클라이언트 처리율은 그림 a에서와 마찬가지이다.

처리율 = min{R1, R2, … , RN} = 서버와 클라이언트 간 경로상에서의 병목 링크(bottleneck link)의 전송률

아래는 오늘날의 인터넷에서 살펴볼 수 있는 다른 두 가지 예시이다.

그림 a는 컴퓨터 네트워크로 연결된 2개의 종단 시스템을 나타낸다.
(전체 네트워크로 보내지는 비트는 서버에서 클라이언트로만 보내지는 비트라고 가정)

Rs : 서버가 네트워크에 연결되어 있는 접속 링크 속도
Rc : 클라이언트가 네트워크에 연결되어 있는 접속 링크 속도

통신 네트워크의 코어에 있는 모든 링크가 Rs와 Rc보다 매우 높은 전송률을 가지고 있다.
(실제로도 그렇다. → 오늘날 인터넷의 코어는 작은 혼잡을 경험)

이때도 마찬가지로, 출발지에서 목적지로 흐를 수 있는 비트 속도는 Rs와 Rc의 최솟값과 같다.

처리율 = min{Rc, Rs}

💡 오늘날의 인터넷에서의 처리율에 대한 제한 요소는 전형적으로 접속 네트워크다.

그림 b는 컴퓨터 네트워크의 코어에 연결된 10개의 서버와 10개의 클라이언트를 나타내며,
10개의 동시적인 다운로드가 일어나고 있다. (10개의 클라이언트-서버 쌍)
(현 시각, 이러한 10개의 다운로드가 네트워크에서의 유일한 트래픽이라고 가정)

10개의 다운로드가 통과하는 코어에 하나의 링크 R가 존재한다.

R : 링크 R의 전송률
Rs : 모든 서버 접속 링크가 가지고 있는 속도
Rc : 모든 클라이언트 접속 링크가 가지고 있는 속도

코어에서의 모든 링크의 전송률(속도 R인 하나의 공통 링크는 예외)은 Rs, Rc, R보다 크다고 가정한다.

이때 다운로드의 처리율은 얼마인가?

공통 링크 R의 속도가 크다면 각 다운로드에 대한 처리율은 min{Rs, Rc}이 될 것이다.

하지만 공통 링크 R의 속도가 Rs, Rc와 같은 수준이라면 어떻게 되는가?

e.g., Rs = 2 Mbps, Rc = 1 Mbps, R = 5 Mbps
→ 공유 링크는 각 다운로드에 500 kbps의 처리율을 제공하기에, 각 다운로드에 대한 종단 간 처리율은 500 kbps로 줄어든다.

즉, 코어에서의 공유 링크가 각 다운로드에 대한 병목이 된다.

위의 예시들을 한 줄로 정리하자면 다음과 같다.

💡 처리율은 데이터가 흐르는 링크의 전송률에 의존할 뿐만 아니라 간섭 트래픽에도 의존한다.

위의 질문을 답하기 위한 방법으로는 다음과 같이 두 가지로 존재한다.

1. 인터넷을 구성하는 기본적인 하드웨어 & 소프트웨어 구성요소에 대한 기술 (1.1.1)
2. 분산 애플리케이션에 서비스를 제공하는 네트워킹 인프라스트럭처 관점에서의 인터넷을 기술 (1.1.2)

아래의 그림은 인터넷의 구성요소를 나타낸 것이다.

• Network of Network
• 전 세계적으로 수십억 개의 컴퓨팅 장치를 연결하는 컴퓨터 네트워크

• 컴퓨터 네트워크에 연결된 컴퓨팅 장치
• e.g., 서버 (데스크탑 PC, 리눅스 워크스테이션, 웹페이지 등), 인터넷에 연결된 모든 인터넷 ‘사물들’ (TV, 스마트 워치 등)
• 통신 링크(communication link)와 패킷 스위치(packet switch)의 네트워크로 연결된다.

• 다양한 전송률(transmission rate, 링크 대역폭 또는 bandwidth)을 이용해 패킷(packet = 데이터)을 전송한다.
• 전송률의 단위 : bps(bits per second, 초당 비트 수)
• 동축케이블, 구리선, 광케이블, 라디오 스펙트럼을 포함한 다양한 물리 매체로 구성된다.

• 송신 종단 시스템에서 수신 종단 시스템(목적지)으로 보내진다.
• 송신 종단 시스템이 보내고자 하는 데이터를 세그먼트(segment)로 나누고, 각 세그먼트에 헤더(header)를 부착하여 수신 종단 시스템으로 전송한다.
• 패킷은 목적지에서 원래의 데이터로 다시 조립된다.

• 입력 통신 링크 중 하나
• 도착하는 패킷을 받아서 출력 통신 링크의 하나로 그 패킷을 전달한다. (최종 목적지 방향으로 패킷을 전달)
• 대표적인 두 종류
  • 링크 계층 스위치(link-layer switch) : 보통 접속 네트워크에서 사용
  • 라우터(router) : 보통 네트워크 코어에서 사용

• 패킷이 송신 종단 시스템에서 보내진 후 수신 종단 시스템에 도달하는 동안 거쳐온 일련의 통신 링크와 패킷 스위치를 말한다.
• 패킷은 컴퓨터 네트워크를 통한 경로를 따른다.

• 패킷 스위치와 통신 링크로 이루어진 네트워크
• 종단 시스템에게 다양한 네트워크 접속을 제공한다. (가정용 초고속 접속, 고속 LAN 접속, 이동 무선 접속 등)
• CP(content provider)에게 인터넷 접속을 제공 → 웹 사이트나 비디오 서버를 인터넷에 직접 연결할 수 있게 된다.
• ISP들의 상호 연결💡 인터넷은 종단 시스템을 서로 연결하는 것이므로 종단 시스템에 접속을 제공하는 ISP들도 서로 연결되어야만 한다.
  • 하위 계층 ISP는 국가 & 국제 상위 계층 ISP를 통해 서로 연결한다. - 상위 계층 ISP들은 서로 직접 연결된다.
  • 각 ISP 네트워크는 따로 관리되고, IP 프로토콜을 수행하며, 네이밍(naming)과 주소배정 방식을 따른다.

• 인터넷에서 정보의 송수신을 제어한다.
• 가장 중요한 프로토콜 둘을 통칭하여 TCP/IP라고 한다.
  • TCP(Transmission Control Protocol)
  • IP(Internet Protocol) : 라우터와 종단 시스템 사이에서 송수신되는 패킷 포맷을 기술한다.

• IETF(Internet Engineering Task Force)
  • 국제 인터넷 표준화 기구
  • RFC(Requests for Comment) : IETF 표준 문서
  • TCP, IP, HTTP, SMTP 같은 프로토콜을 정의
• IEEE 802 LAN 표준위원회
  • 이더넷과 무선 와이파이 표준을 기술

• 애플리케이션은 서로 데이터를 교환하는 많은 종단 시스템을 포함하고 있기 때문에 분산 애플리케이션(distributed application)이라고 부른다.
• 인터넷 애플리케이션은 종단 시스템에서 수행되며, 네트워크 코어에 있는 패킷 교환기에서 수행되지 않는다.

💡 패킷 교환기는 종단 시스템 간의 데이터 교환을 쉽게 해주지만, 데이터의 시작과 끝인 애플리케이션에는 관심을 갖지 않는다.

Q.
한 종단 시스템에서 수행되는 애플리케이션이 다른 종단 시스템에서 수행되고 있는 프로그램으로 데이터를 보내도록 하기 위해서는 인터넷에 어떻게 지시할 것인가?

한 종단 시스템에서 수행되는 프로그램이 다른 종단 시스템에서 수행되는 특정 목적지 프로그램으로 데이터를 전달하도록

어떻게 인터넷 인프라스트럭처에 요구하는지를 명시한 것을 소켓 인터페이스라고 한다.

→ 인터넷에 접속된 종단 시스템들은 소켓 인터페이스를 모두 가지고 있다.

💡 소켓 인터페이스는 송신 프로그램이 따라야 하는 규칙의 집합이며, 인터넷은 이 규칙에 따라 데이터를 목적지 프로그램으로 전달하게 된다.

둘 이상의 통신 개체(entity)가 어떤 일을 함께 수행하려면 이들이 다같이 인식하는 프로토콜 즉, 통신 규약이 필요하다.

아래의 그림은 사람 프로토콜과 컴퓨터 네트워크 프로토콜을 나타낸 것이다.

• 메세지의 송수신과 메시지를 송수신할 때 취하는 행동은 프로토콜의 중심에 있다.
• 따라서 하나가 다른 프로토콜을 수행한다면 그 프로토콜은 다른 이들과 상호작용할 수 없으며, 원하는 작업을 수행할 수 없다.

• 통신하는 둘 이상의 원격 개체가 포함된 인터넷에서의 모든 활동은 프로토콜이 제어한다.
• e.g.,
  • 혼잡 제어(congestion-control) 프로토콜 : 종단 시스템에 존재하며, 송수신자 간에 전송되는 패킷 전송률을 조절한다.
  • 라우터에서의 프로토콜 : 출발지(source)에서 목적지(destination)까지의 패킷 경로를 설정한다.

💡 프로토콜은 둘 이상의 통신 개체 간에 교환되는 메시지 포맷과 순서뿐만 아니라, 메시지의 송수신과 다른 이벤트에 따른 행동들을 정의한다.

1.2 접속 네트워크

컴퓨터 네트워크(특히 인터넷)의 구성요소에 대하여 자세히 살펴보자.

 

호스트(host), 종단 시스템(end system)

• 인터넷에 연결되는 컴퓨터와 그 밖의 장치들
• 인터넷의 가장 자리를 차지하고 있기 때문에 ‘종단’ 시스템이라고 부른다.
• 종단 시스템은 애플리케이션을 수행하므로 호스트라고도 부르며, 호스트는 클라이언트(client)와 서버(server)로 구분된다.

 

아래는 종단 시스템의 상호작용을 나타낸 그림이다.

1.2.1 접속 네트워크

접속 네트워크(access network)

종단 시스템을 먼 거리에 위치한 다른 종단 시스템까지의 경로 상에 있는 첫 번째 라우터 즉, 가장 자리 라우터(edge router)에 연결하는 네트워크를 말한다.

아래 그림에서의 굵은 선들은 여러 종류의 접속 네트워크들을 나타낸 것이다.

네트워크 접속 기술들에 대하여 차례대로 알아보자.

• 가정 접속 : DSL, 케이블, FTTH, 5G 고정 무선 기술
• 기업(그리고 가정) 접속 : 이더넷, 와이파이
• 광역 무선 접속 : 3G, LTE 4G, 5G

 

가정 접속

• 오늘날(2020년) 가장 널리 보급된 광대역 가정 접속 유형들
  • DSL : 지역 전화 회사(telco)의 기존 로컬 전화 인프라스트럭처를 이용
  • 케이블 : 케이블 TV 회사의 기존 케이블 TV 인프라스트럭처를 이용
• FTTH : 위의 접속 유형들보다 빠른 속도를 제공하는 미래 기술

 

DSL(Digital Subscriber Line) 인터넷 접속

가정은 유선 로컬 전화 서비스를 제공하는 같은 지역 전화 회사(telco)로부터 DSL 인터넷 접속 서비스를 받는다.

 

DSL 모뎀

가정의 DSL 모뎀은 텔코의 지역 중앙국(Central Office, CO)에 위치한 DSLAM(Digital Subscriber Line Access Multiplexer)과 데이터를 교환하기 위해
기존 전화 회선을 이용한다.

1. 가정의 DSL 모뎀은 수신한 디지털 데이터를 전화선을 통해 CO로 전송하기 위해, 해당 데이터를 고주파 신호로 변환한다.
2. 여러 가정으로부터의 아날로그 신호는 DSLAM에서 디지털 포맷으로 다시 변환된다.

 

주파수 분할 다중화(Frequency-Division Multiplexing, FDM)

이는 1.3.2절에서 자세히 다룰 예정이다.

가정 전화 회선은 데이터와 전통적인 전화 신호를 동시에 전달하며, 이들은 다른 주파수 대역에서 인코딩된다.

 

주파수 분할 다중화를 통해 단일 DSL 링크가 3개의 분리된 링크인 것처럼 보인다.

이를 통해서 하나의 전화 회선과 인터넷 연결이 동시에 DSL 링크를 공유할 수 있게 된다.

• 고속 다운스트림 채널 : 50 kHz ~ 1 MHz 대역
• 중간 속도의 업스트림 채널 : 40 ~ 50 kHz 대역
• 일반적인 양방향 전화 채널 : 0 ~ 4 kHZ 대역

 

스플리터 (splitter)

• 가정 쪽에 존재한다.
• 역할
  1. 가정에 도착하는 데이터와 전화 신호를 분리
  2. 데이터 신호를 DSL 모뎀으로 전송

 

DSLAM(Digital Subscriber Line Access Multiplexer)

• 수백 ~ 수천 개의 가정들이 DSLAM에 연결된다.
• 역할
  1. 데이터와 전화 신호를 분리
  2. 데이터를 인터넷으로 송신

 

DSL 표준

• DSL 표준은 여러 전송률을 정의하며, 이 전송률에는 업스트림과 다운스트림을 포함된다. (다운스트림 채널이 업스트림 채널보다 빠른 전송률이 할당됨)
  • 업스트림 속도 : 3.5 Mbps, 16 Mbps
  • 다운스트림 속도 : 24 Mbps, 52 Mbps

 

• 최신 표준 : 업스트림과 다운스트림을 결합한 1 Gbps 속도를 정의 (ITU 2014)
  • 다운스트림과 업스트림의 속도가 다르기 때문에 이 접속 방식을 비대칭(asymmetric)이라고 한다.

 

케이블 인터넷 접속, HFC(Hybrid Fiber Coax)

가정은 케이블 TV 서비스를 제공하는 같은 회사로부터 인터넷 접속 서비스를 받는다.

광케이블은 케이블 헤드엔드를 이웃 레벨 정션(junction)에 연결하며, 이로부터 가정들에 도달하는 데에는 전통적인 동축케이블이 사용된다.

헤드엔드(head-end)

• (유선 TV의) 전파 (조정) 중계소, 중계국 / 주전송장치(분배센터)
• 각 데이터 국으로부터 수신된 신호를 많은 세대가 시청할 수 있도록 신호를 가공, 증폭한 다음 분배해주는 시설
• 유선 TV 방송을 위해 전파를 증폭, 조정, 변환, 투입차단 또는 혼합하여 선로로 송출하는 장치들과 신호를 간선 케이블로 송출하는 모든 설비를 말한다.

 

케이블 모뎀

• 케이블 인터넷 접속을 위한 모뎀
• 이더넷 포트를 통해 가정 PC에 연결된다.
• 케이블 헤드엔드에서 CMTS(Cable Modem Termination System)가 존재
• 이는 HFC 네트워크를 다운스트림과 업스트림 채널 2개로 나눈다. (DSL과 똑같음!)
  • 비대칭 접속
  • 다운스트림 채널이 업스트림 채널보다 빠른 전송률이 할당된다.

 

CMTS(Cable Modem Termination System)

• 많은 다운스트림 가정에 있는 케이블 모뎀으로부터 송신된 아날로그 신호를 다시 디지털 포맷으로 변환하는 역할
• 즉, 이는 DSL 네트워크의 DSLAM와 유사한 기능을 한다.

 

케이블 인터넷은 공유 방송 매체 ⭐️

1. 헤드엔드가 보낸 모든 패킷은 / 모든 링크의 다운스트림 채널을 통해 / 모든 가정으로 전달된다.
2. 가정에서 보낸 모든 패킷은 / 업스트림 채널을 통해 / 헤드엔드로 전달한다.

 

이에 다음과 같은 상황이 발생한다.

• 여러 사용자가 다운스트림 채널에서 다른 비디오 파일을 동시에 수신하고 있다면,
  각 사용자가 비디오 파일을 수신하는 실제 수신율은 다운스트림 전송률보다 작아진다.
• 몇 명만 접속 중이며 모두가 웹을 탐색 중이라면, 각 사용자는 전체 다운스트림 전송률로 웹 페이지를 수신할 수도 있다.

업스트림 채널도 공유가 되기 때문에, 분산 다중 접속 프로토콜은 전송을 조정하고 충돌을 피하기 위해 필요하다.

 

FTTH(Fiber to the Home) 인터넷 접속

• 지역 중앙국(Central Office, CO)로부터 가정까지 직접 광섬유 경로를 제공한다.
• 잠재적으로 Gbps의 인터넷 접속 속도를 제공할 수 있다.
• 광신호 분배 기술 : CO로부터 가정까지 광신호를 분해하는 기술들을 말한다.

 

다이렉트 광섬유(direct fiber)

• 가장 간단한 광신호 분배 네트워크
• CO에서 각 가정으로 하나의 광섬유를 제공

 

AON(Active Optical Network)과 PON(Passive Optical Network)

스플리팅을 수행하는 두 가지 경쟁적인 광신호 분배 네트워크 구조들을 말한다.

스플리팅(splitting) : 일반적으로 CO에서 시작되는 각 광섬유는 여러 가정이 공유하기 때문에,
가정에 가까운 곳까지 하나의 광섬유로 온 다음 고객별 광섬유로 분리하는 것

• AON : 근본적인 교환(switched) 이더넷
• PON : 아래 그림 참고 (PON 분배 구조를 이용하는 FTTH 인터넷 접속)이처럼 각 가정에서의 사용자는 홈 라우터를 ONT에 연결하고, 그를 통해 인터넷에 접속한다.
  
  인터넷 접속 절차는 아래와 같이 정리할 수 있다.
  1. 각 가정은 ONT(Optical Network Terminator)를 가지고 있으며, 이는 지정된 광섬유로 이웃 스플리터에 연결된다.
  2. 스플리터(Optical Splitter)는 여러 가정을 하나의 공유 광섬유로 결합, 이를 텔코의 CO에 있는 OLT(Optical Line Terminator)에 연결한다.
  3. OLT는 광신호와 전기 신호 간의 변환을 제공, 이는 텔코 라우터를 통해 인터넷에 연결된다.

• 

  
  
  

 

5G 고정 무선(5G Fixed Wireless, 5G-FW) 기술

• 빔포밍(beam-forming) 기술을 이용하여 서비스 제공가의 기지국에서 가정 내의 모뎀으로 데이터를 무선으로 전송한다.
• 와이파이(WiFi) 무선 라우터가 케이블 또는 DSL 모뎀에 연결되어 있듯, 5G-FW에서도 와이파이 무선 라우터가 모뎀에 연결되어 있다.
• 5G 셀룰러(cellular) 네트워크 → 7장에서 설명

 

기업(그리고 가정) 접속

LAN(Local Area Network)

• 종단 시스템을 가장자리 라우터에 연결하는 데 사용된다.
• 여러 유형의 LAN 기술 중, 이더넷 기술이 기업, 대학, 홈 네트워크에서 가장 널리 사용되는 접속 기술

아래는 전형적인 홈 네트워크를 나타낸 그림이다.

이더넷(Ethernet)

• 이더넷 스위치에 연결하기 위해 꼬임쌍선을 이용 (꼬임 쌍선은 1.2.2절에서 설명)
• 이더넷 스위치 혹은 상호연결된 스위치들의 네트워크는 다시 더 큰 인터넷으로 연결된다.

 

무선 랜(wireless LAN) 환경

점차 사람들은 인터넷을 ‘사물(스마트폰, 태블릿 등)’에서 무선으로 접속하고 있다.

• 무선 랜 환경에서 무선 사용자들은 기업 네트워크에 연결된 AP(Access Point)로 패킷을 송•수신
• AP는 유선 네트워크에 다시 연결된다.
• 와이파이(WiFi) : IEEE 802.11 기술에 기반한 무선 랜 접속

 

광역 무선 접속

• 무선 인프라스트럭처를 채택 (이동 전화망 사업자들이 운영하는 기지국을 통해 패킷을 송수신하는 데 사용하는 것과 같은 것임)
• 수십 미터 반경 내에 있어야 하는 와이파이와 달리, 사용자는 기지국의 수십 킬로미터 반경 내에 있으면 된다.

1.2.2 물리 매체

인터넷에서 공통적으로 사용하는 물리 매체들과 그 밖의 매체들에 대하여 살펴보자.

 

물리 매체(physical media)

물리 매체를 정의하기 위해서는 비트에 대해 먼저 알아야 한다.

 

한 종단 시스템에서 여러 링크와 라우터를 거쳐 다른 종단 시스템으로 한 비트가 전달되는 상황을 생각해보자.

• 이 비트는 여러 라우터를 거치게 된다. (첫 번째 라우터 : 비트를 수신 & 전송 → 두 번째 라우터 : 비트를 수신 & 전송 → 세 번째 라우터 : … )
• 즉, 비트는 출발지에서 목적지로 전달될 때 여러 번 걸쳐 전송되며, 일련의 송신기-수신기 쌍을 거친다.

 

비트는 물리 매체(physical media)상에 전자파나 광 펄스를 전파하여 전송한다.

• 물리 매체는 여러 형태이며, 경로상의 각 송신기-수신기 쌍에 대해 같은 유형일 필요는 없다.
• e.g., 꼬임쌍선, 동축케이블, 다중모드 광섬유 케이블, 지상파와 위성파 등
• 두 가지 종류
  • 유도 매체(guided media) : 꼬임쌍선, 동축케이블, 광섬유 케이블과 같은 견고한 매체를 따라 파형을 유도
  • 비유도 매체(unguided media) : 무선 랜 혹은 디지털 위성 채널처럼 야외 공간으로 파형을 전파

 

꼬임쌍선

• 가장 싸고 가장 많이 이용하는 전송 매체 (전화기에서 전화국 스위치까지 유선 연결의 99% 이상이 이를 이용)
• 구성
  • 2개의 절연 구리선, 각각은 약 1mm 굵기로 규칙적인 나선 형태로 배열된다.
  • 이웃하는 쌍들 간에 전기 간섭을 줄이기 위해 선들이 꼬여 있는 것이며, 이러한 한 쌍의 선이 하나의 통신 링크를 구성한다.
• 데이터 전송률 : 전송선의 두께, 송신기와 수신기 사이의 거리에 따라 다르다.
• 사용 : UTP(Unshielded Twisted Pair) - 빌딩의 컴퓨터 네트워크, LAN에서 가장 많이 이용하는 매체

 

동축케이블

• 구조 : 꼬임쌍선처럼 2개의 구리선으로 되어 있으나, 두 구리선이 평행하지 않고 동심원 형태를 이룬다.
• 데이터 전송률 : 동심원 형태의 구조와 특수 절연 및 차폐를 가지고 있어 꼬임쌍선보다 더 높은 데이터 전송률을 얻을 수 있다.
• 사용 : 케이블 TV 시스템
• 특징
  • 유도 공유 매체(shared medium)으로 사용할 수 있다.
  • 여러 종단 시스템은 케이블에 직접 연결할 수 있고, 모든 종단 시스템은 다른 종단 시스템이 전송하는 모든 것을 수신한다.

 

광섬유

• 비트를 나타내는 빛의 파동을 전하는 가늘고 유연한 매체
• 초당 10~100기가비트에 이르는 높은 비트율을 지원한다.
• 광 장비는 고가이므로 근거리 전송(LAN, 가정)에는 이용하기 어렵다.
• 특징
  • 전자기성 간섭에 영향을 받지 않는다.
  • 100 km까지는 신호 감쇠 현상이 매우 적다.
  • 태핑(tapping, 도청)하기가 어렵다.
• 사용 : 해저 링크, 광역 전화 네트워크

 

지상 라디오 채널

• 전자기 스펙트럼으로 신호를 전달한다.
• 특징
  • 물리 선로를 설치할 필요가 없다.
  • 벽을 관통할 수 있다.
  • 이동 사용자에게 연결성을 제공하며, 먼 거리까지 신호 전달이 가능하다
  • 전파 환경과 신호가 전달되는 거리에 많은 영향을 받는다.
    • 주변 환경을 결정하는 요소
      • 경로손실(path loss)
      • 섀도 페이딩(shadow fading) : 신호가 먼 거리를 지나감에 따라 / 방해 물질을 돌아가거나 통과함에 따라 신호 강도가 약해지는 현상
      • 다중경로 페이딩 : 간섭 물체의 신호 반사 때문에 발생
      • 간섭 : 다른 라디오 채널이나 전자기 신호 때문에 발생
• 크게 3개의 그룹으로 분류
  • 1~2 m의 매우 짧은 거리에서 동작하는 채널 (무선 헤드셋, 키보드 등)
  • 로컬 라디오 채널 : 십~수백 미터에 걸쳐 근거리 네트워크로 동작하는 채널 (무선 랜 기술)
  • 광역 라디오 채널 : 수십 킬로미터에 걸쳐 광역에서 작동하는 채널 (셀룰러 접속 기술)

 

위성 라디오 채널

• 지상 스테이션이라는 둘 이상의 지상 기반 마이크로파 송신기/수신기를 연결한다.
• 과정
  1. 한 주파수 대역으로 전송 신호를 수신
  2. 리피터(repeater)를 통해 그 신호를 재생
  3. 그 신호를 다른 주파수 대역으로 전송
• 전송률 : 초당 기가비트
• 두 가지 종류
  • 정지 위성(geostationary satellite) : 지상 36,000 km에 쏘아올려져 일정 위치에 영원히 머무름
  • 저궤도 위성(low-earth orbiting(LEO) satellite) : 지구를 공전하며 지상국뿐만 아니라 서로 통신할 수 있음
    → 미래의 인터넷 접속에 이용될 수도?

1. Introduction to PyTorch

Pytorch : Dynamic Computation Graph

TensorFlow: Define and Run

cf) Define and Run: 그래프를 먼저 정의 -> 실행시점에 데이터 feed

cf) Define by Run: 실행을 하면서 그래프를 생성하는 방식

Define by Run의 장점: 즉시 확인 가능, pythonic code

GPU support, Good API and Community, 사용하기 편함,

TensorFlow는 production 과 scalability의 장점이 있다.

PyTorch의 장점 (Numpy, AutoGrad, Function)

numpy구조를 가지는 Tensor 객체로 array 표현, 자동미분 지원 DL연산 지원, 다양한 형태의 DL을 지원하는 함수와 모델 지원

2. PyTorch Basics

PyTorch Operations

"numpy + AutoGrad"

a는 copy가 아님, b는 copy -> 주로 view를 쓰면됨

• view는 오직 contiguous한 tensor에만 적용할 수 있으며, reshape은 이러한 제약이 없다.
• view는 원래 tensor와 메모리를 공유하며, reshape도 가능한 경우에는 원래 tensor와 메모리를 공유한다.
•  

3. PyTorch 프로젝트 구조 이해하기

upyter Notebook으로 코드를 관리할 때 일반적으로 발생할 수 있는 어려움

• 쉬운 코드 재현이 어려울 수 있다.
• 실행 순서가 꼬일 가능성이 존재한다.