[기술면접 대비] 4. CS 공통 - 네트워크

네트워크, 인터넷, 웹

여러 통신 장비가 데이터를 공유할 수 있게 연결된 디지털 통신망 네트워크가 있고, 이를 이용하는 가장 큰 네트워크 통신망이 인터넷. 웹은 인터넷을 통해 이용하는 서비스 중 하나이다. 

 

인터넷 상의 데이터 전달

packet switching : 중간중간 라우터를 거쳐가며 패킷을 전달.

 - 회선을 점유하지 않고 바로 다음 라우터에 보내가면서 최종 목적지로 도달. 

 - 패킷 단위로 움직여야 함. 라우터는 패킷의 끝부분까지 다 도달할 동안 기다린 다음 단계로 이동을 시작함.

 - 인터넷 사용자 수의 제한이 없다. (동시에 네트워크 요청을 하는 접속자가 터지면 문제가 생기긴 함 ex 수강신청)

*circuit switching : 출발지부터 최종 목적지까지 미리 길을 다 닦아놓음. 점유함. 옛날 유선전화 통신방식

 

packet delay 

1. processing delay : 패킷의 다음 목적지 탐색 등에 시간이 걸림.

 - 라우터의 성능을 향상시켜 개선 가능

2. queueing delay : 라우터에 들어온 패킷이 순차적으로 queue에서 대기하다 outgoing하는데 queue에서 대기중에 걸리는 시간. 이 때 packet이 몰려서 대기 queue가 터지면 packet 유실이 발생함. (패킷 유실의 90%가 큐에서 발생)

인터넷 사용자의 다이나믹한 접속 패턴에 달려있으므로 조절 불가.

3. transmission delay : 내 패킷이 나갈 때 첫 비트부터 마지막 비트가 빠져나가는 순간 동안 걸리는 시간

 - link bandwidth의 크기를 늘려 개선 가능 (케이블 공사, 회선 증가)

4. propogation delay : 내 패킷의 마지막 비트가 나간 순간부터 다음 목적지까지 도달하는 동안 걸리는 시간 (조절 불가)

 

* TCP 통신은 신뢰성을 보장해야 함. queueing 에서 발생한 패킷 유실을 어떻게 처리하는가?

 - 패킷이 유실되면 처음부터 다시 전송하게 함.

유실되기 직전 라우터에서 보내주면 더 좋겠지만 그렇게되면 라우터의 성능이 저하됨.

기본적으로 네트워크 엣지에서 복잡한 기능을 담당하고, 중간 단계 라우터는 단순한 전달작업만 전담함.

 

응용계층 HTTP

클라이언트-서버간 응용 어플리케이션 통신. 

request와 response로 동작.

하위 계층인 전송, 네트워크, link 계층을 기반으로 함.

 

socket

네트워크 상에서 통신하는 프로그램들의 통신 최종 목적지 Endpoint

하위 계층인 전송 계층을 기반으로 하며 TCP 소켓/ UDP 소켓 두 가지 타입이 있다 . 

read()/write()로 데이터를 주고받음

 

*TCP/UDP 소켓과 웹소켓

1. TCP/UDP 소켓 : 네트워크 상에서 데이터를 송수신하기 위한 통신 최종 목적지. 

데이터를 바이트 스트림으로 전송

2. 웹소켓 : 웹 상에서 실시간 양방향 통신을 지원하기 위해 HTTP 프로토콜에 기반해 탄생한 프로토콜. http와 동일하게 80, 443 포트를 사용한다

데이터를 UTF-8 인코딩 메시지 스트림으로 전송.

 

서버 소켓 API

1. socket() : 소켓 열기. 생성된 소켓의 ID를 리턴. 파라미터로 도메인, 소켓 타입(TCP/UDP) 등을 지정

2. bind() : 소켓과 특정 포트번호를 바인딩. 파라미터로 소켓 아이디와 포트번호를 지정

3. listen() : 서버니까 listen으로 소켓을 사용하겠다 지정. 파라미터로 소켓 아이디와 backlog 지정

*backlog : 동시 요청시 queue에서 대기시킬 최대 소켓의 양 

4. accept() : 클라이언트 요청을 받을 준비 완료, 파라미터로 소켓 ID, 소켓 주소를 지정하고 클라이언트 요청이 들어옹면 클라이언트 ID와 클라이언트 주소를 추가로 지정함.

5. connect() : 클라이언트와 연결

 

클라이언트 소켓 API 

1. socket() : 소켓 열기

2. connect() : 서버 소켓에 연결 요청

 

전송계층 공통

multiplexing 과 demultiplexing

1. multiplexing : 데이터를 보낼 때(send) 상위 계층의 다양한 응용프로세스로부터 전달받은 data(payload)에 TCP또는 UDP헤더를 붙여 segment를 만들고 이를 하위 계층으로 내려줌

2. demultiplexing : 데이터를 받을 때 하위 계층으로부터 전달된 segment를 상위 계층의 다양한 응용 프로세스 중 알맞은 타겟에 전달

 

demultiplexing TCP와 UDP의 차이

1. UDP : connectionless demux. 응용프로세스의 소켓을 찾을 때, 목적지 IP주소 + 목적지 Port 번호만을 봄. 출발지와 고유한 연결이 없음

2. TCP : connection oriented demux. 응용프로세스의 소켓을 찾을 때, 출발지 IP주소+출발지 Port번호 + 목적지 IP주소 + 목적지 Port번호를 모두 봄. 출발지와 목적지간의 고유한 연결을 기반으로 소켓을 찾아감.

 

UDP 프로토콜

- 신뢰성 낮음

- 헤더구조 (8바이트) : source port, dest port, length, checksum

 1) source/dest port : 각각 2바이트씩(PC당 2^16개의 포트넘버가 존재 할 수 있다), 출발지/목적지 포트번호

 2) length : 길이, 2바이트

 3) checksum : 헤더 오류 체크, 2바이트

 

패킷의 reliable 원칙

1. 패킷 Error 감지, 피드백 전송

 - 센더와 리시버 모두 Ack/NAck 비트 이용(seq#). 리시버로부터 응답 비트를 보고 재전송 여부 판단.

2. 패킷 유실 감지, 

 -  Ack/NAck 비트 이용, 센더는 timer를 추가로 사용. 특정 시간동안 리시버로 부터 응답이 아예 오지 않으면 재전송.

한계 : 한 번에 하나의 패킷만 주고받는 상황에서만 사용 가능

 

여러 패킷을 보내는 상황에서 reliable

1. go-back-N

 - n개의 window size만큼 전송. Ack/NAck번호는 누적 seq#값. (Ack i 는 i번째까지 패킷이 모두 무사히 도달했음)

리시버는 단순히 누적 Ack 값 다음 패킷만 기다림. 중간 유실 또는 에러 발생 시 i번째부터 n개를 모두 중복전송해야하는 문제.

한계: 중복 재전송이 너무 많음

2. selective repeat 

- Ack를 누적하지 않고 개별 패킷에 대해 사용. 리시버는 버퍼를 두어 패킷이 순서대로 도달하지 않아도 받은 패킷을 일단 저장하고 Ack를 보내줌. Ack응답을 받지 못 한 패킷만 선택적으로 재전송. Ack 범위 최소화 = window size *2 

한계 : 패킷마다 timer를 갖고 있어야 함.

 

TCP 프로토콜

1. 특징

 - point to point : 한 쌍의 소켓간의 통신을 책임짐(connection oriented)

 - reliable, in-order : 패킷 에러/유실 방지, 순서 보장 (Seq&Ack 번호 사용)

 - full-duplex data : 센더-리시버는 고정적이지 않음. 양 쪽이 모두 센더와 리시버 역할을 할 수 있음

 - sender/receiver buffer : full-duplex 이므로 두 버퍼를 모두 가지고 있음  

 - flow controll : sender는 recevier가 수용 가능한 양 만큼만 조절해 전송 (남은 버퍼의 크기를 알려주는 window 필드)

 - congestion controll : sender는 리시버 버퍼 뿐만 아니라 네트워크 상황을 고려해 전송

RTT send 후 리시버에게서 ack 응답을 받기까지 걸리는 시간

 

congestion control

- TCP는 네트워크 상황이 악화될 수록 더욱 악화시키게 동작함 (재전송 때문)

- 따라서 아예 네트워크 상황이 악화되지 않도록 방지해야 함. 어떻게?

1. network-assisted : 네트워크가 직접 자기 상황을 알려줌. 비현실적. 라우터는 멍청함

2. End-end : send에 대한 Ack 응답을 가지고 유추함. 실제로 사용. 정확성은 떨어짐

 

End-end 동작 원리

1. slow start : MSS를 겸손하게 시작해서 2배씩 증가시킴

2. additive increase : MSS를 threshold 시점 이후부터 linear하게 조금씩 증가시킴

3. multiplicative decrease : 문제가 생기면 MSS의 크기를 절반으로 확 줄임

*MSS(Maximum segment size)

*threshold는 어떻게 설정? 터지는 시점에 MSS크기 줄이면서 기존 크기의 절반값으로 설정해줌

 

TCP reno

네트워크 상황이 악화되었는지는 응답을 본다했음. 근데 응답이 유실된 경우 두가지 존재 가능

1. 3 duplicated Ack : 네트워크 상황이 악화된건지 확실하지 않음(특정 요청만 문제가 있을 수 있음).  이 경우는 MSS를 1로 확 떨구는 게 아니라 절반으로만 줄이고 threshold를 그 값으로 재설정함. 빠른 회복이 가능함

2. timeout : 네트워크 상황이 악화된 것. 이 경우엔 사이즈를 1로 확 줄여버림. threshold를 재설정하지 않음

 

네트워크 프로토콜

IP란? 호스트의 Network Interface를 지칭하는 주소.

호스트가 여러개의 네트워크 장비(NIC, LAN카드 등)를 가지면 여러 IP를 가지기도 한다. ex)라우터

IP는 네트워크 ID(prefix)와 호스트 ID로 구분되며 서브넷 마스크로 이를 구분함

서브넷은 동일한 prefix를 가지는 네트워크 장비들의 집합을 의미. 즉 라우터를 거치지 않고 접근 가능한 호스트들의 집합을 의미함

라우터는 포워딩 테이블을 보고 가장 길게 매칭되는 네트워크 ID가 적힌 곳으로 패킷을 전송함.

 

Forwarding Table

각각의 라우터는 라우팅 알고리즘을 통해 출발지부터 목적지까지의 경로를 선택함

이를 기록해놓는 테이블이 포워딩 테이블

특정 포트로부터 요청이 들어오면 포워딩 테이블을 참조해 다음 라우터로 포워딩시킴

 

라우팅 알고리즘

1. link-state : intra-AS 알고리즘. 네트워크 망 내의 모든 라우터들이 이어진 그래프를 다 알고있는 상태로 최단경로를 찾음. 모든 라우터는 브로드캐스트를 날려 근접 라우터의 정보를 기록하고 있음. 그래프를 이용해 다익스트라 알고리즘 사용.

2. distance vector : intra-AS알고리즘. 네트워크 망 내의 모든 라우터들이 이어진 정보를 모름. 나와 근접한 라우터에 대한 경로만 알고 있으므로 내 이웃만을 가지고 전체경로를 유추함. dx(y) = min{c(x,v) + dv(y)}의 형태로 재귀적 호출.

3. hierachical Routing : inter-AS알고리즘. 네트워크 망 간의 경로를 결정함. intra와 달리 최단경로라는 명확한 목적이 존재하지 않음. 네트워크간의 위상이 다르며 다양한 이해관계가 얽힘. 갑을이 명확한 경우 provider와 customer의 관계가 생성되며, 서로간의 위상이 유사한 경우는 peer를 이룸. 최단경로를 보장하지 않음.

*AS 자치권이 있는 시스템. 각각의 네트워크 망은 해당 네트워크를 관장하는 자치권을 가짐

 

게이트웨이 역할을 하는 라우터가 기본적으로 제공하는 기능들

1. DHCP

2. NAT

3. DNS

4. Firewall

 

NAT 

주소변환장치

라우터에서 사설 IP를 공인 IP로 변환해서 통신함.

레이어간 violation 발생.

source IP와 Port를 모두 바꾸기 때문에 3계층 장비가 4계층 레이어까지 열어서 데이터를 변경함,

게다가 원래 IP는 호스트를 찾아가고, Port번호는 해당 호스트의 프로세스를 찾기 위함이었는데 NAT사용으로

IP는 게이트웨이를 찾아가고, Port번호는 해당 호스트를 찾아가게 하는 방식으로 변질됨 

 

DHCP, Dynamic Host Configuration Protocol

동적으로 host 정보(호스트 IP, 서브넷 마스크, DNS IP, Router IP 등)을 할당해주는 프로토콜

임시로 빌려주고 일정 시간(end time)이 경과하면 회수함

원래 DHCP 서버가 따로 있지만 보통 라우터에 해당 기능을 내장해서 사용함

동작과정

DHCP discover : 클라이언트가 서브넷 내에 DHCP 서버를 찾는 브로드캐스팅을 날림.

(IP는 255.255.255.255 대신 포트번호는 DHCP 포트인 67으로)  

이 때 클라이언트는 IP주소가 아직 없는 상태라 source가 0.0.0.0으로 세팅. 

DHCP offer : DHCP 서버로 동작하고 있던 장비가 해당 요청을 받고(포트번호 67번) 사용 가능한 정보(IP, end time, DNS IP, Router IP)를 담아 또다시 브로드 캐스팅으로 응답을 줌.

why? 요청을 보낸 상대는 IP가 아직 없으므로. 대신 port번호와 transmission Id정보를 가지고 찾아갈 수 있음

DHCP request : 클라이언트는 받아들일 오퍼의 정보를 포함해 다시 브로드 캐스팅으로 응답함

why? 서브넷 내에 여러 DHCP서버가 존재할 경우 다양한 오퍼를 받을 수 있음. 선택한 오퍼 정보를 브로드캐스팅을 보냄으로써 DHCP서버들이 해당 클라이언트가 오퍼를 수락했는지 드랍했는지 알 수 있음. 이 때까지 클라이언트 IP는 미정이므로 0.0.0.0임.

(DHCP Ack : DHCP 서버의 최종 확인) 이 이후부터 클라이언트는 IP를 비롯한 정보를 가지게 됨.

 

데이터 link 레이어

네트워크 장비가 게이트웨이 라우터로 각자의 신호를 전달할 때 사실 독립된 하나의 회선을 통하는 것이 아니라 전 회선에 broadcast됨. 따라서 이러한 broadcast medium들의 충돌을 방지하기 위한 기법이 필요함.

 

Medium Access Control 프로토콜 (MAC)

1. 채널링 : 일정 시간 또는 주파수를 할당함

2. Taking Turn : 중앙에 제어장치를 두고 토큰을 발행

3. 랜덤 액세스 : 대표적으로 CSMA/CD모델 사용. 랜덤하게 말 하는 대신 listen before transmission으로 이미 전송중인 프레임 시그널이 있으면 기다렸다 전송함. 또한 전송을 시작했어도 collision이 일어나게 되면 충돌을 감지하고 전송을 중단한 뒤 랜덤한 시간 뒤 재전송함. 실제 이더넷 프로토콜이 채택한 방식.

 

이더넷 프로토콜

- CSMA/CD 방식을 사용. 따라서 CD로 인한 재전송 기능을 담당함(link레이어에서의 재전송임. TCP재전송과 다름)

- propogation delay로 인해 충돌이 일어났음에도 감지하지 못 하는 상황이 있을 수 있어 최소 전송 단위를 가짐.

아무리 전송할 시그널의 크기가 작아도 최소 64byte까지 무의미한 패딩을 붙여 혹시 뒤늦게 발생했을 collision을 감지함.

* 이더넷 프로토콜 헤더의 주소는 | 목적지 | 출발지 | 순서로 다른 프로토콜과 반대!

 

스위치와 라우터

switch는 Link layer 디바이스. 스위치 테이블을 가지며, 사실상 네트워크 환경에서는 스위치를 인식하지 않음(중간에 스위치를 거쳐도 목적지 주소를 스위치로 세팅하지 않음). 동일한 서브넷 내에서 확장하기 위해 사용. 기본적으로 데이터 링크간의 collision domain을 분리해주기 때문에 서로 다른 domain간의 통신은 동시 통신이 가능함.

router는 네트워크 계층 디바이스. (+a로 DNS, DHCP, NAT 등의 기능도 제공하기도 함) 포워딩 테이블과 ARP테이블을 가지고 라우팅을 함. 서브넷이 분리됨. 공유기는 라우터다.

 

Link layer의 Wireless / Mobility 

wireless는 무선. 

mobility는 이동. 네트워크 상의 이동은 물리적 이동을 기준으로 하지 않고, 실제로 AP가 변경되는 이동을 의미 (스마트폰)

 

Wireless 

네트워크 전체가 아니라 첫 홉을 기준으로 함. 즉 디바이스부터 첫 스위치 혹은 라우터까지

외부로부터 간섭이 존재. 

거리가 멀어질수록 신호 세기가 약해짐

전송거리에 따라 신호세기가 달라 충돌 감지 불가능

 

Wi-Fi (IEEE 802.11)

대표적인 무선 프로토콜

AP (Access Point)를 통해 네트워크에 접근한다.

BSS(Basic Service Set)

passive scanning 모든 AP는 beacon 프레임에 담아 주기적으로 자신의 정보를 브로드캐스팅하고, 호스트는 AP의 신호를 받아 연결을 판단.

 

CSMA/CA

디바이스는 AP와 무선으로 통신하는 것이 목표. 하지만 충돌을 감지할 수 없으니 어떻게 할 것인가?

기본 과정

1) 센더는 listening하다가 조용해지면 랜덤한 시간만큼 대기하고(DIFS) 전송

2) 리시버로부터 전송에 대한 피드백(Ack)을 받아 전송이 이루어졌는지를 판단

* Link layer의 Ack는 TCP의 Ack와 다르다

무선은 충돌감지 대신 피드백을 받음. 그러나 충돌이 일어나면 즉시 전송을 멈춰서 자원 낭비를 방지하는 CSMA/CD와 다르게 한 번 보내기 시작한 자원은 충돌 발생 여부를 모르니 끝까지 전송됨.

즉 충돌이 일어날 경우 낭비되는 자원의 큼!

따라서 애초에 충돌을 피하기 위한 기법이 필요하다. 이를 위한 추가적인 기법이 RTS-CTS

 

RTS-CTS

RTS ready to send : 센더가 보냄.

 조용해졌을 때 대기 후 바로 데이터를 보내지 않고 RTS라는 작은 사이즈의 control 프레임을 먼저 전송

CTS clear to send : 리시버가 보냄.

 센더로부터 RTS를 받으면 CTS라는 피드백을 보내서 전송을 허락함.

* RTS가 충돌 등으로 유실되었다면 자동적으로 CTS를 못 받았으니 다시 random backoff동안 물러나서 대기

RTS와 CTS는 모두 브로드캐스팅 된다. 즉, AP 통신반경의 모든 디바이스가 해당 신호를 받아서 AP가 허락한 경우가 아니면 모두 대기한다. CTS 피드백의 대상이 되는 디바이스만 안전하게 데이터를 전송하게 된다.

여전한 문제상황

AP가 브로드캐스팅한 CTS를 다양한 이유로(충돌 유실, CTS 전송 후 새로 진입) 전달받지 못 한 디바이스들은 전송을 허락받은 디바이스가 데이터를 보내고 있을 때 다시 RTS를 보내면서 충돌을 일으킬 수 있음. 충돌로 인한 유실로 서로 재전송을 하며 경쟁이 심화됨. 

따라서 무선 환경에서는 사용자가 많아질수록 충돌 지연이 증가할 수 밖에 없다.

 

와이파이 구조

| 프레임 컨트롤 | duration | 주소1 | 주소2 | 주소3 | seq 컨트롤 | 주소4 | ~데이터~ | CRC |

* 크기 (2 | 2 | 6 | 6 | 6 | 2 | 6) 바이트

프레임 컨트롤 (16비트) 영역 상세

| 프로토콜 버전 | 타입 | 서브타입 | from AP | to AP | more frag | .... 등등

* 크기 (2 | 2 | 4 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | ) 비트

* 와이파이 프레임의 타입은 RTS, CTS, data. Ack 총 네 가지 중 하나 (따라서 2비트 사용)

 

주소 필드가 총 3개 (주소4는 패스)

주소1 : 데이터를 받는 인터페이스의 MAC 주소 (목적지)

주소2 : 데이터를 전송하는 인터페이스의 MAC주소 (출발지) 

주소3 : 데이터를 처리하는 라우터의 MAC주소 (목적지)

>> 무선 데이터 프레임은 중간에 AP를 거쳐서 라우터로 전송된다!

AP는 디바이스들과는 무선 WiFi프로토콜을 사용하고 라우터와는 유선 이더넷 프로토콜을 사용.

중간에서 무선 데이터 프레임을 이더넷 데이터 프레임으로 변환하거나(전송) 그 반대의 역할(수신)을 수행한다.

* 라우터 입장에서 link 레이어 디바이스인 AP는 안 보임(스위치 처럼)

ex)

1) 디바이스 H1이 전송할 때

 H1 > (Wi-Fi) | AP 주소 | H1 주소 | 라우터 주소 |  > AP > (이더넷) | 라우터 주소(목적지) |  H1주소(출발지) | > 라우터

2) AP를 거쳐 수신할 때

 라우터 > | H1주소 | 라우터 주소  | > AP > | H1 주소 | AP 주소 | 라우터 주소 | > H1

 

AP의 통신 과정 심화

1. AP의 MAC주소를 알아내는 방법 

애초에 AP가 주기적으로 쏘는 비컨 메시지에 자신의 MAC주소 정보를 함께 담고 있음.

따라서 특정 AP를 선택해 연결했다면 자동으로 AP주소를 알게된다.

2. 무선 디바이스에서 라우터 주소 알아내기

1) 디바이스 H1은 자기 자신에 대한 정보를 얻기 위해 가장 처음 DHCP 통신을 진행 

 H1 > | AP 주소 | H1 주소 | 브로드캐스트(아직 몰라) |  > AP > | 브로드캐스트 | H1주소 | > DHCP

*  이 때 네트워크 계층의 주소는 다음과 같다 | 0.0.0.0 (아직 모름) | 255.255.255.255(브로드캐스트) |

2) DHCP서버가 동작하고 있는 디바이스가 offer를 보내줌

 DHCP >  | 브로드캐스트 | DHCP주소  |  > AP > | 브로드캐스트(H1이 아님) | AP 주소 | 라우터 주소 | > H1

* 이 때 네트워크 계층의 주소는 다음과 같다 | DHCP IP 주소 | 255.255.255.255(브로드캐스트) |

* DHCP로부터 받은 응답은 IP와 MAC이 모두 브로드캐스트인데 어떻게 H1이 받는가? 마지막 계층인 어플리케이션 레이어까지 패킷을 열어보고 transmission ID를 통해 알게됨.

3) DHCP를 통해 IP주소, 서브넷 마스크, 라우터 IP, 로컬 DNS IP등을 알게되었으니 라우터 IP를 이용해 ARP 테이블을 참조하거나 ARP 통신을 하여 MAC주소를 알아냄. 

>> 사실상 2번 단계에서 DHCP서버로부터 응답을 받을 때 라우터의 MAC주소를 알게 되었다! 따라서 3번에서는 ARP테이블에 라우터 IP와 MAC주소가 적혀있으므로 추가적인 ARP 통신 불필요

 

가정용 무선 공유기의 정체는?

AP도, 라우터도 아님! 

AP의 기능과 라우터의 기능을 모두 가지고 있으며,

그 위에 어플리케이션 레이어까지 갖춰진 훨씬 똑똑한 쟈근 컴터!

 

Mobility

 

 

 

웹 프로토콜과 통신과정 

OSI 7Layer 모형에서 7계층에 속하는 프로토콜로 대표적으로 http 프로토콜이 있다. 클라이언트/서버 간 Request/Response 동작에 기반해 서비스를 제공한다. Connectionless, 비연결성의 속성으로 요청-응답 후 연결을 끊어 트래픽을 점유하지 않는다. Stateless, 무상태 속성으로 이전 상태를 유지하지 않으므로 정보 유지를 위해 쿠키나 세션 등의 기술이 필요하다.

4계층 TCP 프로토콜에서 3way handshake를 통해 먼저 프로세스와 프로세스간의 연결수립과정이 일어난다. 클라이언트가 서버에 연결 요청을 보내고, 서버가 클라이언트에 수락 패킷을 전송하면 다시 클라이언트가 최종 수락 패킷을 보낸다. 그 후 연결수립 과정에서 주고받은 Seq번호와 Ack번호를 가지고 http 등의 프로토콜이 각종 데이터를 주고받는다.

기존의 http1.0은 요청에 대한 응답을 한 번 받으면 TCP 연결까지 해제하기 때문에 이어지는 통신에도 연결수립과정이 계속해서 반복되었다. 하지만 1.1 버전은 데이터 송수신이 모두 완료되기까지 TCP연결을 끊지 않는다.

클라이언트의 Request는 크게 요청 타입(GET, POST 등), URI, HTTP 버전 정보를 담고있는 Request Line과 쿠키를 비록한 각종 header정보, 메세지 바디를 가진다.

응답 프로토콜은 HTTP버전, 상태코드, 상태문구를 담는 Response Line과 마찬가지로 각종 쿠키를 생성하고 클라이언트에 전송하는 등의 정보를 담은 header 및 메시지 바디를 보낸다. 대표적인 상태 코드로는 200 정상응답, 404 Not Found 등이 있다.

 

HTTP와 HTTPS

HTTP는 HyperText Transfer Protocol, 인터넷 상에서 하이퍼 텍스트를 전송하기 위해 사용되는 통신규약.

HTTP는 정보를 단순 텍스트로 주고받기 때문에 네트워크 상에서 전송 신호를 인터셉트하면 데이터 유출이 발생할 수 있다. 이러한 보안상의 이슈를 해결하기 위해 HTTP에 Source Socket을 추가해 SSL을 사용함으로써 암호화된 연결을 제공하는 프로토콜이 HTTPS.  SSL 인증서는 클라이언트와 서버간 통신을 제 3자가 보증하는 전자문서이다. 

 

GET 방식과 POST 방식

GET은 서버로부터 데이터를 가져오기 위해, POST는 서버에 데이터를 전송하기 위해 사용된다.

GET은 간단한 데이터를 URL에 포함해 전송한다. 최대 길이에 제한이 있고 특정 문자의 경우 인코딩되어야 하며 보안에 매우 취약하다. URL 뒤에 ?를 시작으로 파라미터를 작성하고 &로 구분한다.

POST는 URL에 데이터를 노출하지 않고 body에 포함시킨다. GET방식과 달리 전송 기록을 캐싱할 수 없으며, 헤더에 데이터 타입을 명시해주는 Content-Type을 함께 기재한다. 길이 제한은 없지만 최대 요청시간이 존재한다. 

 

Web socket

클라이언트와 서버 사이의 지속적인 양방향 연결 스트림을 만들어 주는 기술. 

실시간 양방향 통신을 지원하며 한 번 연결이 수립되면 추가적인 연결수립과정 없이 클라이언트와 서버가 연속적으로 데이터를 주고받을 수 있다.

 

http와 같이 7계층 프로토콜이며 4계층 TCP에 의존해 연결수립 과정 이후 동작함.

최초 연결 요청은 HTTP 프로토콜을 이용하며 2 way hanshake를 수행. http 헤더에 “Connection:Upgrade”와 “Upgrade:websocket” 를 명시해 웹소켓 요청임을 알리고, “Sec-WebSocket-Key”로 핸드쉐이크 응답을 검증할 키값을 함께 전송함.

연결이 수립되면 protocol switching을 통해 http 프로토콜을 웹소켓 프로토콜로 전환한다.

 

WebSocket 객체를 생성할 때는 필수 파라미터인 연결 url과 서브 프로토콜을 지정하는 선택 파라미터인 프로토콜 문자열을 받는다.

소켓이 생성된 다음에는 커넥션이 만들어지는 open, 데이터를 주고받는 message, 소켓 에러를 처리하는 error, 커넨션을 종료하는 close, 총 네 가지의 이벤트를 사용한다.

데이터를 전송 할 때는 send()메서드를 사용하며, 데이터 수신은 이벤트 핸들러인 onmessage 메서드로 전달된다.  

 

Servlet 과 JSP

둘 다 java를 기반으로 하는 웹 기술. sevlet은 java 코드 안에 html 코드로 웹 개발을 위해 만든 표준이다. jsp는 html 안의 java 코드로 서블렛을 보완하고 기술을 확장한 스크립트 방식. 

 

18. API 

www.redhat.com/ko/topics/api/what-are-application-programming-interfaces

응용 프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 어플리케이션 프로그래밍 인터페이스. 세부적인 구현 방식을 알지 못해도 도큐먼트에 의거해 서비스를 이용할 수 있으며 개발 시간과 비용을 절약가능. 자체 인프라를 연결하는 간소화된 방식에서부터 퍼블릭 API로 확장해 외부 사용자에게 데이터 공유를 허락하기도 함. 소프트웨어가 다른 소프트웨어로부터 지정된 형식에 따라 요청, 명령을 받을 수 있는 수단.

 

19. RESTfull API

과거의 SOAP 형식을 대체한 REST 아키텍쳐의 조건을 준수하는 웹 API.

URI와 메서드(GET, POST, PUT, PATCH 등) 요청 형식만으로도 내용을 추론 가능하게 설계하는 것이 핵심. 

레스트를 구성하는 제약조건

 - client-sever

 - stateless

 - cache

 - uniform interface : 리소스는 URI로 식별 가능해야 한다. 리소스 조작은(CRUD) 해당 표현을 통해야 한다(전송 메서드), 메시지는 스스로 설명 가능해야 한다. 애플리케이션의 상태는 항상 하이퍼링크를 통해 전이되어야 한다(HATEOAS)

 - layered system

 - code-on-demand : 서버에서 클라이언트로 코드를 보내 실행 할 수 있어야 한다.(JS) 

왜 쓰냐? 서버와 클라이언트의 독립적인 진화를 위해

 

20. 쿠키와 세션

HTTP 프로토콜의 클라이언트가 요청 후 응답을 받으면 연결을 끊어버리며(connectionless) 클라이언트의 상태 정보를 유지하지 않는(stateless) 특성을 보완하기 위해 사용함.

쿠키란? 클라이언트(브라우저) 로컬에 저장되는 키,밸류 쌍의 데이터 파일. 인증 유효시간을 명시할 수 있으며 브라우저가 종료되어도 유효시간동안 인증이 유지됨. 하나의 도메인 당 20개의 값을 가질 수 있다.  클라이언트가 페이지를 요청하면 서버는 Response Header에 Set-Cookie를 명시해 쿠키를 내려준다. 이 후 클라이언트는 요청 헤더에 쿠키 정보를 포함시켜 보낸다. 아이디`비밀번호 저장, (비로그인 상태의)장바구니, 자동로그인, 더 이상 이 창을 보지 않음 등의 기능에 사용됨.

세션이란? 쿠키와 달리 서버에서 관리하는 데이터. 클라이언트 구분을 위해 세션 ID를 부여함. 서버가 임의로 인증 유효 시간을 정할 수 있지만 클라이언트가 브라우저를 종료하면 바로 삭제된다. 클라이언트가 서버에 접속하면 세션 ID를 발급받아 쿠키에 저장한다. 이 후 통신에서 클라이언트는 쿠키의 세션 ID를 함께 서버에 요청하고, 서버는 해당 ID로 서버에 저장된 클라이언트 정보를 가져와 요청을 처리한다. 로그인 등 보안상 중요한 작업을 수행함. 브라우저마다 발급이라 새 탭은 동일 세션 유지.

쿠키는 서버 자원을 사용하지 않으며 처리 속도가 빠르고, 세션은 보안에 강하다.

+내가 사용한 경험?

 

자동로그인 로직 

로그인 쿠키 3대장 : 사용자 이름 + 고유 식별자 + 가변 토큰 

1. 자동로그인 체크 후 로그인 시 표준 세션관리 쿠키와 함께 로그인 3대장 쿠키 발행.

2. 로그인 쿠키 쌍은 서버의 DB에 저장됨

3. 추후 사용자가 로그인 쿠키를 제시할 때 세 쌍이 있는 사용자는 인증 된 것으로 간주

4. 사용된 토큰을 폐기하고 새 토큰을 생성해 DB 업뎃하고 사용자에게는 새 로그인 쿠키 발급

5. 사용자 이름, 고유식별자는 동일한데 토큰 정보가 일치하지 않다면 도난으로 간주하고 경고를 발생. 세션 삭제

6. 사용자 이름, 식별자가 없으면 로그인 쿠키 무시

 

CORS 

Cross-Origin Resource Sharing, 교차 출처 리소스 공유. 

웹 어플리케이션은 보안상의 이슈로 동일 출처 정책에 따라 자기가 실행중인 출처와 동일한 출처로부터만 리소스를 받을 수 있다. 즉, 호스트와 출처가 다른 곳으로부터 자원을 받지 못 함. 

이 때 동일한 출처(Same-Origin)을 판단하는 기준은 기본적으로 scheme(프로토콜)://host(도메인):port 까지를 의미한다 (IE는 예외적으로 port번호 달라도 Same-Origin 취급함 developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)

브라우저는 요청 프로토콜 헤더의 Origin 항목과 응답 프로토콜의 Access-Control-Allow-Origin 항목을 비교하고 서로 다르다면 에러를 발생시킨다. 즉 판단은 서버나 클라이언트가 이닌 브라우저가 하므로 서버 응답 자체는 200 OK로 제대로 들어와있는 경우가 있음.

이를 해결하기 위한 가상 정석적인 방법은 애초에 동일한 출처를 사용하거나, 리소스를 보내주는 서버에서 응답 헤더에 Access-Control-Allow-Origin 값에 접근하고자 하는 도메인을 명시하는 것.

혹은 프론트 쪽에서 프록시에 리소스를 받아올 도메인을 등록해 사용 할 수 있지만, 빌드 후 배포하면 안 먹힘.