코딩하는 eroke

HTTP & HTTPS

HTTP : Hypertext Transfer Protocol : HTML 전송을 위한 통신규약

HTTP 동작 순서 : TCP → HTTP

HTTPS 동작 순서 : TCP → SSL → HTTP

SSL(Secure Socket Layer)프로토콜 = TLS(Transport Layer Security) : 정보를 암호화시킴 

• 대칭키 : 암호화 키 = 복호화 키 
• 공개키-개인키 : 두개의 키/ 공개키-암호화, 개인키(비밀키)-복호화 
• SSL 동작법 : 클라이언트-서버 주고받는 실제 데이터 = 대칭키 / 대칭키의 키 = 공개키

RSA : SSL/TLS에 가장 많이 사용되는 공개키 암호화 알고리즘 (이름 뜻 : 개발한 세 사람의 성을 따서 만든거;)

 - 공개키로 암호화 > 개인키로만 복호화 / 개인키로 암호화 > 공개키로만 복호화 

모든 사이트가 HTTPS로 하지 않는 이유 : 암호화 과정으로 인한 속도 저하 발생

GET & POST

가장 많이 사용되는 HTTP 메서드로 HTTP 프로토콜을 이용해 서버에 무언가 요청할 때 사용하는 방식이다.

GET (select) : 데이터 조회, 검색
URL을 통해 모든 파라미터를 전달 > 주소창에 전달 값이 노출됨. URL 길이가 제한이 있기 때문에 전송 데이터 양이 한정되어 있고, 형식에 맞지 않으면 인코딩해서 전달해야 함 

POST (수행) : 데이터/서버의 값이나 상태 변경 (등록, 수정)
HTTP BODY에 데이터를 포함해서 전달 > 웹 브라우저 사용자의 눈에는 직접적으로 파라미터가 노출되지 않고 길이 제한도 없음.

하기 메소드들은 POST 메소드로도 구현 가능하다. 좀더 기능을 세부화 했다고 보면 된다.

• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제

그외

• HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
• CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

Reference

인터넷에서 데이터는 효율적인 라우팅을 위해 패킷 단위로 쪼개져 같은 목적지로 전송되며

TCP는 패킷에 각각 번호를 부여하여 목적지에서 재조립한다. (패킷 분실 확인 처리/ 패킷 추적)

패킷의 구성 : 헤더 (수신단 인터넷 주소, 순서) / 데이터 / 테일러 (에러정보)

1. 흐름제어 (정지-대기, 슬라이딩 윈도우)

송수신단 사이 데이터 처리속도 차이를 제어 > 데이터 처리속도를 조절해 수신자의 버퍼 오버플로우 방지

1) 정지-대기 (stop and wait)

매번 패킷에 전송 후 정지-대기, 확인 응답 받은 뒤 다음 패킷 전송가능

> 비효율적

2) 슬라이딩 윈도우 (sliding window)

윈도우 : 송수신단에서 만들어진 버퍼크기

수신단에서 설정한 윈도우 크기 만큼 송신단에서 확인 응답이 없어도 세그먼트 전송 가능 (연속적)

> 데이터 흐름 동적 조절

2. 오류제어 (ARQ : 정지-대기, GBn, SR)

ARQ (Auto Repeat Request) : 자동 반복 요청. 프레임 손상/손실 시 재전송 요청 (흐름제어와 연관성)

1) 정지-대기 ARQ

송신단에서 1개 프레임을 전송하면 수신단에서 ACK 혹은 NAK 전송 (에러 유무 응답)

• ACK : 다음 프레임 전송
• NAK : 손상된 프레임 번호 반환

데이터 프레임과 ACK 프레임은 0,1 번호를 번갈아 부여하여 구분

NAK응답/ 데이터, ACK 분실 시 타임아웃 > 재전송 

2) Go-Back-n ARQ

프레임 손상/분실, ACK 손실로 인한 타임아웃 시 확인된 마지막 프레임 이후 모든 프레임 재전송

송신단은 전송한 프레임의 복사본을 가짐 (ACK, NAK 구분)

수신단은 NAK 이후 수신 데이터는 폐기하고 재전송 받는다

3) SR ARQ (Selective-Reject ARQ)

손상/손실된 프레임만 재전송 (GBn ARQ의 모든 프레임을 재전송하는 단점 보완)

별도의 데이터 재정렬, 버퍼 필요 : 수신단에 버퍼를 두어 수신데이터 정렬 (비용증가)

3. 혼잡제어 (AIMD, Slow Start)

하나의 라우터에 데이터가 몰려 모든 데이터 처리가 어려울 때 > 호스트들 재전송 > 혼잡가중 > 오버플로우/데이터 손실 발생 가능

네트워크 혼잡을 피하기위해 송신단의 데이터 전송/처리속도를 제어하는 기법

1) AIMD (Additive Increase Multicative Decrease)

합 증가 - 곱 감소 알고리즘

• 패킷 1개 전송 > 전송한 패킷이 문제 없이 도착 > 윈도우 사이즈 +1 하며 전송
• 전송 실패/타임아웃 > 윈도우 사이즈 절반 감소

나중에 진입 > 초기엔 불리하지만 결국엔 시간 흐르면 공평해짐

문제점 : 초기에 높은 대역폭 사용 못함 (처음에 전송속도 올리는데 많은 시간 소요), 네트워크 혼잡성 미리 감지 못함

2) Slow Start

AIMD 와 시작 같음 (시작 느림)

ACK마다 윈도우 사이즈 +1 > 한 주기 이후 윈도우 사이즈=2배 

혼잡 현상 발생했던 윈도우 사이즈 절반 까지는 지수 함수 꼴로 윈도우 증가, 이후 +1씩 증가

• 혼잡 회피 : 윈도우 크기가 임계 값에 도달하면 데이터 손실 가능성 높음 > 회피하기 위해 윈도우 선형증가(+1) > 혼잡하면 윈도우 크기 세그먼트 후 1로 감소 + 임계값을 손실 발생했을 때의 윈도우 사이즈 절반으로 감소
• 빠른 회복 : 혼잡상태 > 윈도우 사이즈 절반으로 감소 > 선형증가(+1)
• 빠른 재전송 : 중복된 순번의 패킷 3개 수신 시 재전송, 윈도우 사이즈 절반으로 감소

Reference

서버 : socket() 생성 → bind() 소켓 주소할당 → listen() 연결요청 대기상태 → accept() 연결허용 → read/write() 데이터 송수신 → close() 연결종료

클라이언트 : socket() 생성 → connect() 연결요청 → read/write() 데이터 송수신 → close() 연결종료

3-way handshake : TCP 연결

서버 listen() 상태 

1) 클라이언트 connect(), C->S 접속요청 패킷 SYN(M) 전송  

2) 서버 accept(), S->C 요청 수락 패킷 ACK(M+1), SYN(N) 전송 

3) 클라이언트 connect(), C->S 요청 수락 확인 패킷 ACK(N+1) 전송

연결 성립 (Established)

4-way handshake : TCP 해제

Established 상태

1) C->S 연결 종료요청 FIN FLAG 전송

2) S->C 종료 수락 메시지 ACK 전송

   일시적 TIME_OUT (데이터를 모두 보낼 때 까지)

3) S->C 연결 종료 FIN FLAG 전송

4) C->S 확인 메시지 ACK 전송

서버 소켓 연결 close(), 클라이언트 일정 시간 동안 TIME_WAIT (잉여패킷 대기)

TCP flag(URG, ACK, PSH, RST, SYN, FIN)

FLAG 순서  - | URG  | ACK | PSH | RST | SYN | FIN |

각각 1비트로 TCP 세그먼트 필드 안에 CONTROL BIT 또는 FLAG BIT 로 정의 되어 있다.

SYN(Synchronization:동기화) - S : 연결 요청 플래그

TCP 에서 세션을 성립할 때  가장먼저 보내는 패킷, 시퀀스 번호를 임의적으로 설정하여 세션을 연결하는 데에 사용되며 초기에 시퀀스 번호 (ISN) 를 보내게 된다.

시퀀스 랜덤인 이유
Connection시 사용하는 포트는 유한 범위 내 사용되고 시간이 지나면 재사용 됨
= 두 통신 호스트가 과거 사용된 포트 번호쌍을 사용할 가능성이 있음 
>>> SYN의 시퀀스가 순차적일 경우 서버에서는 SYN으로 패킷 구분하므로 이전 Connections에서 오는 패킷으로 인식 가능  

ACK(Acknowledgement) - Ack : 응답

상대로부터 패킷을 받았다는 걸 알려주는 패킷, 다른 플래그와 같이 출력되는 경우도 있음
수신자가 송신자 시퀀스 번호에 길이 또는 데이터 양을 더해 ACK를 전송 (일반적으로 +1)

ACK 응답을 통해 보낸 패킷에 대한 성공, 실패를 판단하여 재전송 하거나 다음 패킷을 전송

FIN(Finish) - F : 연결 종료 요청
세션 연결을 종료시킬 때 사용. 더이상 전송할 데이터가 없음을 나타냄

RST(Reset) - R : 연결 종료
재설정(Reset)을 하는 과정, 양방향에서 동시에 일어나는 중단 작업

비 정상적인 세션 연결 끊기. 현재 접속하고 있는 곳과 즉시 연결을 끊고자 할 때 사용

PSH(Push) - P : 밀어넣기

받은 데이터를 버퍼가 채워지기를 기다리지 않고 (버퍼링 없이) 즉시 목적지인 OSI 7 Layer 의 Application 계층으로 전송

TELNET 과 같은 상호작용, 빠른 응답이 중요한 프로토콜(대화형 프로토콜)에 사용

URG(Urgent) - U : 긴급 데이터
Urgent pointer가 유효한 것인지를 나타냄. 긴급 데이터로 다른 데이터에 비해 우선순위가 높아야 함 
(ex. ping 명령어 실행 도중 Ctrl+c 입력)

Placeholder             
패킷의 플래그에 SYN, FIN, RST, PSH등의 플래그가 설정 되어 있지 않은 경우 세팅됨

ACK플래그와 함께 사용되기도 함

Reference

Transport Layer (TCP vs UDP)

OSI 7계층의 하위 3계층과 상위 3계층의 인터페이스를 담당 (TCP/UDP : OSI 전송계층의 표준)

<물리계층 - 데이터링크계층 - 네트워크계층 - 전송계층 - 세션계층 - 표현계층 - 응용계층>

1. TCP (Transmission Control Protocol) - 전송제어 프로토콜

1) 전이중(full-duplex) 방식 : 전송 양방향으로 동시에 가능

2) 점대점(point to point)방식 : 각 연결이 2개의 종단점을 가지고 있음 

신뢰성 없는 인터넷을 통해 송수신 종단점(소켓) 간에 신뢰성있는 바이트 스트림 전송 

특징

연결형, 신뢰성(흐름제어, 오류제어), 순차성, 멀티캐스팅 지원 X, 브로드캐스팅 지원 X

• 연결 : 3-way handshake
• 해제 : 4-way handshake
• 흐름제어 : 슬라이딩 윈도우
• 오류제어 : 재전송

2. UDP (User Datagram Protocol) - 사용자 데이터그램 프로토콜

1) IP 데이터그램 캡슐화하여 전송

2) 연결 설정 없이 전송

3) 짧은 요청, 응답에 용이

포트들을 사용해 IP 프로토콜에 인터페이스 제공

클라이언트-서버 상황에 유용 (단일/다중 목적지로 전송 가능)

● DNS : 사전설정, 해제 필요 없음

1) 어떤 hostname의 IP주소를 찾을 때, DNS 서버로 hostname이 포함된 UDP패킷 전송

2) DNS 서버는 hostname이 포함된 UDP 패킷으로 응답 

● 실시간 멀티미디어 

RTP (Real time Transport Protocol) : UDP 패킷의 단일 스트림으로 몇몇 실시간 데이터 스트림을 멀티플렉싱

패킷에 번호를 부여하여 분실 패킷 추적 가능 

특징

비연결형, 신뢰성 X(흐름/오류제어 없음), 순차전달 X

Reference