Blue Peach

대부분 응용 프로그램이 네트워크 연결을 기반으로 개발되어 네트워크 프로토콜과 기술이 발전하고 있다. 

일반적인 네트워크 애플리케이션은 2개의 서로 다른 종단 시스템에 존재하는 Client 프로그램과 Server 프로그램으로 구성되어 있다. Client와 Server 프로그램을 수행하면, Client와 Server 프로세스가 소켓으로부터 읽고, 소켓에 쓰기를 통해서 서로 통신한다. 

응용프로그램에서 만든 데이터는 소켓을 통해 운영체제로 전달되어 TCP/IP 계층을 통해 원하는 목적지에 전달된다.

앞에서 계속 언급하고 있는 소켓이란, 운영체제 계층 간의 인터페이스 역할을 하는 것이라고 할 수 있다. 

데이터에 헤더를 붙이는 위치가 운영체제에서는 전송계층부터 붙는다.

UDP를 이용한 소켓 프로그래밍

1. 송신 프로세스가 데이터의 패킷을 소켓 문밖으로 밀어내기 전에, UDP를 사용할 때 먼저 패킷에 목적지 주소를 붙여 넣어야 한다. 
2. 패킷이 수신 소켓에 도착하면 수신 프로세스는 소켓을 통해 그 패킷을 추출하고 다음에 패킷의 콘텐츠를 조사하고 적절한 동작을 취한다.
3. 목적지 호스트 IP 주소가 목적지 주소의 일부가 된다.
4. 패킷에 목적지 주소를 포함함으로써 인터넷의 라우터는 목적지 호스트로 인터넷을 통해 패킷을 라우터 할 수 있다.

호스트는 하나 혹은 그 이상의 소켓을 갖는 많은 네트워크 애플리케이션 프로세스를 수행하고 있을 수 있기 때문에 목적지 호스트 내의 특정한 소켓을 식별할 필요가 있다. 

▶ 소켓이 생성될 때 포트 번호라고 하는 식별자가 소켓에 할당된다.

패킷의 목적지 주소

 : 호스트 IP 주소 + 소켓의 포트 번호

 → 소스 주소를 패킷에 붙이는 것은 UDP에는 하지 않은다.(하부 운영체제가 자동으로)

TCP를 이용한 소켓 프로그래밍

TCP는 연결지향 프로토콜로, Client와 Server가 서로에게 데이터를 보내기 전에 먼저 TCP 연결을 설정할 필요가 있음을 의미한다. 

1. TCP 연결을 생성할 때 Client 소켓 주소(IP 주소와 포트 번호)와 Server 소켓 주소(IP 주소와 포트 번호)를 연결과 연관시킨다.
2. TCP 연결 후에 한쪽에서 다른 쪽으로 데이터를 보내려면 소켓을 통해 데이터를 TCP 연결로 보내면 된다.

클라이언트 프로그램에서 TCP 소켓을 생성함으로써 가능하다. 클라인언트는 TCP 소켓을 생성할 때 서버에 있는 서버의 IP주소와 소켓의 포트 번호를 명시한다. 소켓을 생성한 후 클라이언트는 세 방향 핸드셰이크를 하고 서버와 TCP 연결을 설정한다. (전송계층에서 일어나는 3-handShake를 클라이언트와 서버 프로그램은 전혀 인식 못함)

▼

서버 쪽에서 새롭게 생성된 소켓 생성인 연결 소켓와 혼동한다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

TCP 연결이 설정된 후, 한쪽에서 다른 쪽으로 데이터를 보내려면 소켓을 통해 데이터를 TCP 연결로 보낸다.

UDP는 TCP와 달리 서버가 패킷을 소켓에 제공하기 전에 패킷에 목적지 주소를 붙여야 한다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

애플리케이션 관점에서 볼 때 클라이언트의 소켓과 서버의 연결 소켓은 파이프에 의해 직접 연결된다. 클라이언트 프로세스는 자신의 소켓으로 임의의 바이트를 보낼 수 있으며 보낸 순서대로 서버 프로세스가 바이트를 수신하도록 TCP가 보장한다.(TCP::신뢰적 서비스 제공[송수신 가능])

위키백과에 따르면, 

P2P는 비교적 소수의 서버에 집중하기보다는 '망'구성에 참여하는 기계들의 계산과 대역폭 성능에 의존하여 구성되는 통신망이다.라고 나와 있다. 

▶ 이전에 작성한 글들은 왼쪽 그림처럼 서버 중심의 중앙 집중형 시스템을 사용하여 서버에 의존하는 형태였다면,

오른쪽 그림처럼 P2P 구조는 이름에서 알 수 있듯이 특정 서버를 통하지 않고 피어(사용자가 제어하는 개인 PC)가 서로 직접 통신하는 형태이다. 

장점 

1. 중앙 서버가 없기 때문에 중앙 서버가 해킹되거나 변조되는 일이 없음

2. 서버의 부하가 줄어들거나 사용작가 분담할 수 있도록 하여 비용을 줄일 수 있음

3. 피어 수가 늘어나면 파일 전송 속도가 올라감

단점

1. 모든 클라이언트가 서버 역할을 대신하기 때문에 자신의 IP주소가 다른 클라이언트에게 노출됨

2. 피어 수가 적으면 파일 전송 속도가 떨어짐

3. 데이터 처리와 통신 작업의 분담으로 클라이언트의 컴퓨터 성능을 높여야 함

client-server와 P2P 구조 비교

1. P2P 구조는 자가 확장성을 가지고 있다. 

▶ 위의 내용을 설명하기 위해 파일 분배하는 방법을 확인하자. 

**분배 시간은 모든 N개의 피어들이 파일의 복사본을 얻는 데 걸리는 시간

분배 시간에 대한 분석에서 client-server와 P2P 구조 모두의 경우, 인터넷 코어가 풍부한 대역폭을 갖고 있다는 가정 한다. 또한 client-server는 다른 네트워크 애플리케이션에 참여하지 않아서 이들의 모든 업로드와 다운로드 접속 대역폭은 이 파일 분배에 모두 사용된다고 가정한다. 

(F: 분배되는 파일의 크기)

먼저 client-server 구조에 따르면,

1. 서버는 파일 복사본을 N개의 피어 각각에서 전송해야 한다. 따라서 서버는 NF 비트를 전송해야 한다. 서버의 업로드 속도가 ㎲이기 때문에 파일을 분배하는 시간은 적어도 NF/㎲이다. 
2. dmin이 가장 작은 다운로드 속도를 가진 피어의 다운로드 속도를 나타낸다고 가정한다. 
3. 가장 낮은 다운로드 속도를 가진 피어는 F/dmin초보다 적은 시간에 파일의 모든 F 비트를 얻을 수 없다. 따라서 분배 시간은 적어도 F/dmin이다.

수식을 보면 분배 시간은 피어의 수 N에 따라 선형적으로 증가한다. 예를 들어, 한 주에서 다음 주까지 피어의 수가 천에서 백만으로 천 배 증가한다면, 파일을 모든 피어들에게 분배하는 데 필요한 시간도 천 배 증가한다.

P2P 구조를 살펴보면

client-server 구조보다 복잡한다. 이유는 분배 시간이 각 피어가 다른 피어에게 파일의 일부를 어떻게 분배하느냐에 달려 있기 때문이다. 

1. 분배가 시작되면 서버만이 파일을 갖고 있다. 이 파일이 피어 커뮤니티에 도달할 수 있도록 하기 위해, 서버는 적어도 한 번 접속 링크로 파일의 각 비트를 보내야 한다. 따라서 최소 분배 시간은 적어도 F/㎲이다. (client-server와 달리 피어들 사이에 해당 비트를 재분배할 수 있기 때문에 서버가 한 번 보낸 비트는 다시 보낼 필요가 없다.)
2. client-server와 같이 가장 낮은 다운로드 속도를 가진 피어는 F/dmin초이다. 
3. 시스템의 전체 업로드 용량은 전체적으로 서버의 업로드 속도와 각 피어들의 업로드 속도를 더한 것이다. 시스템은 N개 피어들 각각 F 비트를 전달 (업로드) 해야 한다. 이는 Utotal보다 더 빠른 속도로 할 수는 없다. 따라서 최소 분배 시간은 NF/(us+u1+....+un)이다.

(현실에서는 개별적인 비트보다는 파일의 청크(chunk)가 재분배됨)

모든 피어가 같은 업로드 속도 u를 갖고 있다고 가정하고 최소 분배 시간을 비교하면,

피어는 전체 파일을 한 시간 안에 보낼 수 있고, 서버 전송 속도는 피어 업로드 속도의 10배이며, 피어 다운로드 속도는 영향을 받지 않을 정도로 충분히 크게 설정된다. (=> 항상 client-server 구조보다 분배 시간이 적은 건 아니다.)

- client-server 구조는 피어의 수가 증가함에 따라 분배 시간이 선형적으로, 한계 없이 증가한다. 

- P2P 구조는 피어들이 파일을 요구함으로써 작업 부하를 만들지만 각 피어들은 또한 파일을 다른 피어들에게 분배해 서비스 능력을 추가한다.

■ P2P 구조의 자기 확장성은 피어가 비트의 소비자이자 재분배자인 것의 직접인 결과다.

2. P2P 구조는 비용이 효율적이다.

▶ 일반적으로 상당한 서버 기반구조와 서버 대역폭을 구하지 않기 때문이다. 

비트토렌트

: 파일 분배를 위한 인기 있는 P2P 프로토콜

: 음악, 영화, 문서 등 다양한 파일을 인터넷상에서 P2P방식으로 공유할 수 있도록 하는 플랫폼

여기서 토렌트는 파일의 분배에 참여하는 모든 피어들의 모임이다.

△ 트랙커 : 1) 기반구조 노드, 2) 토렌트에 가입할 때 트랙커에 등록하고 주기적으로 트랙커에서 알림 , 3) 토렌트에 참여하는 피어들을 추적

1. 새로운 피어 앨리스가 토렌트에 가입할 때 트랙커는 참여하고 있는 피어 집합에서 임의로 피어들의 부분 집합을 선택하여 피어들의 IP주소를 앨리스에게 보냄

2. 피어들의 리스트를 얻고 나서, 앨리스는 리스트에 있는 모든 피어들과 동시에 TCP 연결을 설정

3. TCP 연결이 성공적으로 설정된 모든 피어들은 이웃 피어라 부름 -> 시간이 지남에 따라 이웃 피어들이 떠나고 다시 TCP 연결을 함

4. 임의의 주어진 시간에 각 피어는 파일 청크들의 일부를 갖고 있으며, 서로 다른 피어들은 다른 부분을 갖고 있음

5. 앨리스는 TCP 연결을 통해 이웃 피어들에게 갖고 있는 청크 리스트 요구(앨리스가 갖고 있지 않는 청크 요구)

▷ 앨리스는 피어 중 가장 드문 것을 갖고 있는 피어에게 먼저(rarest first) 요구 => 이웃들 중에 가장 적은 반복 복사본을 가진 청크를 결정

▶ 비트토렌트는 TFT(tit-for-tat) 방식을 사용한다. TFT는 눈에는 눈, 이에는 이라는 말로 반복 게임에서, 경기자가 이전 게임에서 상대가 한 행동을 이번 게임에서 그대로 따라 하는 전략을 말한다. 

TFT 없이 설계했다면 대부분의 사용자들은 무임승차하기 때문에 비트토렌트는 존재하지 않았을 것이다.

P2P 구조의 다른 예

쉰레이(Xunlei) :: 피어-지원 다운로드 가속기

스카이프 :: 인터넷 전화 및 비디오 콘퍼런스

암호화폐와 블록체인 :: 중앙 통화 발행자나 교환소 없이 사용자가 결제를 처리하고 확인할 수 있는 네트워크

블루투스 :: 중앙 서버나 서비스의 개입 없이 일대일로 연결

-"컴퓨터 네트워킹 하향식 접근 제7판" 참고했습니다.

1. 웹 캐시란?

1. 원출처의 웹 서버를 대신하여 HTTP 요구를 충족시키는 네트워크 개체이다.
2. 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존한다.

2. 웹 캐시의 종류

1. 프록시 캐시(Proxy Cache)

: 한정된 사용자의 네트워크 서비스의 병목 현상을 해결하기 위해 내부에 웹 프록시 서브를 구성하여 빠르고 효율적인 서비스 목적으로 구성한다.

▶원 서버와의 통신 트래픽 강도를 낮추는 역할을 한다.

2. 브라우저 캐시(Browser Cache)

: 사용자의 브라우저에 웹 객체를 저장하여 서버의 요청을 줄이고, 빠른 웹 서비스를 제공한다.

3. 웹 캐싱(Caching)_프록시 서버

1. 사용자는 프록시 서버와 TCP 연결 설정하고  HTTP 요청을 한다.

2. 프록시 서버는 사용자의 사용 내용이 사본이 저장된 객체가 존재하면 응답해 주고,

없으면 원 서버와 TCP 연결 설정하고 HTTP 요청하여 응답받은 객체를 저장한다.

3. 객체 사본을 응답한다.

4. 웹 캐시의 장점

1. 웹 캐시는 클라이언트의 요구에 대한 응답 시간을 줄인다.

특히, 클라이언트와 원출처 서버 사이의 병목 대역폭이 클라이언트와 캐시 사이의 병목 대역폭에 비해 매우 작을 때 더욱 효과적이다.

2. 웹 캐시는 한 기관에서 인터넷으로 접속하는 링크상의 웹 트래픽을 대폭 줄일 수 있다.

트래픽을 줄이면 기관은 자주 대역폭을 개선할 필요가 없게 되므로 비용을 줄일 수 있고, 모든 애플리케이션을 위한 성능을 개선을 할 수 있다.

HTTP는 웹페이지 URL을 입력할 때 사용해서 익숙할 것이다. 그렇다면 HTTP는 무엇일까?

HTTP는 웹 클라이언트인 브라우저가 웹 서버에게 웹 페이지를 어떻게 요청하는지, 서버가 클라이언트로 어떻게 웹 페이지를 전송하는지를 정의한 것이다.  즉, 클라이언트-서버로 구현된 웹의 애플리케이션 계층 프로토콜이다.

웹은 종단 시스템(=호스트)인 클라이언트와 서버가 서로 HTTP 메시지를 교환하며 통신하다.

브라우저는 페이지 내부의 객체에 대한 HTTP 요청 메시지를 서버에게 보내면 서버는 요청을 수신하고 객체를 포함한 HTTP 응답 메시지를 전송한다. 이때 HTTP는 TCP를 전송 프로토콜로 사용한다. 클라이언트와 서버가 요청이 이루어지면, 브라우저와 서버 프로세스는 소켓 인터페이스를 통해 TCP로 접속한다.

HTTP의 서버에서 구현하는 웹 서버(Web Server)인 아파치와 IIS는 URL로 지정할 수 있는 웹 객체를 갖고 있다. 

1. HTTP 프로토콜은

1. 온-디맨드 서비스의 특성을 가지고 있다.

▶ 모든 서비스의 정보들이 서버에 존재하는 것이다. 다시 말해, 사용자가 원할 때 원하는 것을 수신할 수 있다.

2. 비상태 프로콜(Stateless)이다.

▶ HTTP 서버는 클라이언트에 대한 정보를 유지, 저장하지 않는다. 그래서, 클라이언트가 몇 초 후에 같은 객체(단일 URL)를 요청해도, 서버는 전에 한 일을 기억하지 않으므로 다시 그 객체를 보낸다.

예) 로그인이 필요 없는 웹 서비스

3. 요청과 응답 애플리케이션 데이터의 헤더 구조이다.

4. 비지속 연결과 지속 연결 모두 사용할 수 있다.

▶ 비지속 연결은 요청과 응답이 분리된 TCP 연결을 통해 보내진다.

1. HTTP 클라이언트가 포트 번호를 통해 호스트 서버로 TCP 연결을 시도한다. TCP 연결은 소켓 인터페이스를 통해서 한다. (소켓 인터페이스는 클라이언트와 TCP, 서버와 TCP 연결 사이에서의 출입구 역할을 한다.)
2.  설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지와 경로 이름을 포함해서 보낸다. 
3. HTTP 서버는 설정된 연결 소켓을 통해 요청 메시지를 받아 저장장치에서 (경로 이름) 객체를 추출하고 응답 메시지에 그 객체를 캡슐화하여 소켓을 통해 클라이언트에게 보낸다.
4. HTTP 서버는 TCP 연결을 끊으라고 명령한다.
5. HTTP 클라이언트가 응답을 받으면 TCP 연결을 중단한다.

객체가 더 있다면 위와 같은 방식을 반복한다. 예를 들어 설명한 이 방법은 각 TCP 연결은 하나의 요청 메시지와 하나의 응답 메시지만 전송한다.

[단점]

1. 요청이 다르면 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다.

이는 TCP 버퍼가 할당되어야 하고 TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 한다. 수많은 클라이언트가 요청을 동시에 서비스하는 웹 서버라면 엄청난 부담을 줄 수 있다.

2. 각 객체는 2 RTT(패킷이 클라이언트에서 서버로 , 서버에서 클라이언트로 돌아오는 시간) 필요하다.

TCP 연결 설정에 1 RTT, 객체를 요청하고 받는 데 1 RTT가 필요하다는 것이다.

▶ 지속 연결은 요청과 응답이 같은 TCP 연결상에서 보내진다.

1. 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다. 

비지속 연결은 요청마다 TCP를 연결해야 했다면 지속 연결은 같은 클라이언트와 서버 간의 이후 연결과 응답은 같은 연결을 통해 보내진다. 이는 전체 웹 페이지를 하나의 지속 TCP을 통해 보낼 수 있고, 같은 서버에 있는 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 보낼 수 있다.

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

→ 한 번의 연결로 여러 데이터를 요청/응답하여 처리 효율을 높인다.

2. HTTP 통신 과정과 쿠키

와이어샤크를 보면서 실제 연결 과정을 보면,

먼저, 위에 그림처럼 TCP 연결 핸드 셰이킹하며 연결을 한다는 걸 알 수 있다.

또 HTTP은 GET 방식을 사용하여 주어진 URL에서 객체를 요청한다는 것을 알 수 있고,

HTTP/1.1을 통해 지속 연결과 200 OK을 통해 요청에 성공한 상태라는 걸 알 수 있다. 

HTTP 서버는 사용자에 대한 정보를 저장하지 않는 비상태 프로토콜인데, 그렇다면 서버가 사용자 접속을 제한하고 사용자에 따라 콘텐츠를 제공하기를 원한다면 어떻게 해야 할까?

▶ 이럴 경우, 쿠키를 사용하면 된다. 쿠키는 사이트가 사용자를 추적하도록 해준다.

1. HTTP 응답 메시지 쿠키 헤더 라인
2. HTTP 요청 메시지 쿠키 헤더 라인
3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속하는 쿠키 파일
4. 웹 사이트의 백엔드 데이터베이스

사이트에 처음 방문한 사용자는 사용자 확인(ID)을 제공한 후, 세션 동안에 브라우저는 서버에 쿠키 헤더를 전달하여 서버에게 사용자를 확인한다. → 쿠키는 비상태 HTTP 위에서 사용자 세션 계층을 생성하는데 이용될 수 있다.(로그인 후, 사용자 세션 시간 동안 사용자를 식별 가능하다.)

3. HTTP 주요 특성

위에서 설명한 내용들을 정리하면, 

1. 데이터 전송 후 세션 유지 시간은 웹 서버 설정에 의해 결정한다.
2. 처음 요청하여 받은 응답 객체는 브라우저의 메모리에 캐시 저장하고, 같은 요청은 서버에 요청하지 않고 캐시로부터 가져온다.