1. http의 GET과 POST

(1) 공통점

http 프로토콜을 이용하여 서버에 요청하는 경우 사용

(2) 차이점

전송방식

GET : http request meassage의 header에 url 담아 서버로 전송
POST : http request message의 body에 data 담아 서버로 전송

데이터 특성 (크기/보안)

GET : 크기 제한적, 보안에 취약함

데이터를 url에 담기 때문 + 데이터가 url에 드러나기 때문

POST : get보다 크기가 크고, 보안에 덜 취약함

데이터를 body에 담기 때문 + 데이터가 url로 드러나지 않기 때문

binary data 요청 시 post 방식으로 보내야함

용도

GET : 데이터를 가져와서 보여주기 위함 (SELECT적)

POST : 서버의 값 및 상태를 변경, 추가하기 위함

캐싱

GET : 브라우저에 캐싱 가능

POST : 보안이 중요하지 않고 크기가 작은 데이터이기 때문에 GET 대신 POST를 사용하는 경우, 기존의 캐싱된 데이터가 응답할 가능성 존재

2. TCP 연결 성립 과정 (3-way Handshake, 4-handshake)

1. SYN : client -> server
   
   client : ISN 보냄
   
   ISN : 새로운 TCP 연결 시 첫번째 패킷에 할당된 임의의 시퀀스 번호 (장치마다 다름)
   

2. SYN + ACK : server -> client
   
   server : client의 ISN 수신, server의 ISN과 승인번호로 client의 ISN + 1 발신
   

3. ACK : client -> server
   
   client : server의 ISN 수신, 승인번호로 server의 ISN + 1 발신
   

1. FIN : client -> server

client : 연결 닫고자 FIN 세그먼트 전송 후, fin_wait_1 상태되어, 서버의 응답 기다림

2. ACK : server -> client
   
   server : ACK 세그먼트 전송 후, close_wait 상태됨
   
   client : ACK 세그먼트 수신 후, fin_wait_2 상태됨
   

3. FIN : server -> client
   
   server : 일정 시간 후, FIN 세그먼트 전송 후, last_ack 상태됨
   

4. ACK : client -> server
   
   client : time_wait 상태되고, ACK 세그먼트 전송
   
   server : ACK 세그먼트 수신 후, close 상태됨
   
   time wait : client 일정 시간 대기 후 close됨 -> server와 client의 자원연결 해제됨
   

time wait 필요한 이유

• 지연 패킷 발생 대비 위함
  
  (지연 패킷 누락된 경우 데이터 무결성 문제 발생)
  
• 두 장치의 연결 닫힘 여부 확인 위함
  
  (close가 아닌 last_ack에서 새로운 연결 시도 시 접속 류 발생)

3. TCP와 UDP

UDP

• 흐름 제어, 오류 제어, 손상된 세그먼트 수신에 대한 재전송 X
• 사용자 프로세스 몫임
• UDP는 port 사용해 IP 프로토콜의 인터페이스 제공
• 신뢰성, 순차적 전달 만족 X

TCP

• 신뢰성 없는 인터넷 통해 종단 간에 신뢰성 있는 바이트스트림 전송을 위해 설계
• 수신자, 송신자 모두 종단점인 소켓 생성함
• 연결 설정 : 3 way hand shake, 연결 해제 : 4 way hand shake
• 전이중 : 양방향 전송
• 점대점 : 정확한 2개의 종단점 가짐

4. HTTP와 HTTPS

HTTP

문제점 (1) : 평문 통신임으로 도청 가능

• TCP/IP 통신은 전부 경로 상에서 엿볼 수 있어 패킷 수집만으로 도청 가능
• 평문 통신 시 메세지 의미 파악 가능
  
  

보안 방법

• 통신 자체를 다른 프로토콜과 조합해 HTTP 내용 암호화
  
  SSL + HTTP => HTTPS
• HTTP 메세지의 콘텐츠 암호화
  
  전송 받는 측에서 해독해 출력하는 처리 필요

문제점 (2) : 통신 상대 확인 안 해 위장 가능

• req 보낸 웹서버가 이에 대한 res 보내야 하는 웹서버인지 알 수 X
• res 반환하는 곳의 client가 원래 의도한 client이닞 알 수 X
• 통신하는 상대가 접근이 허가된 상대인지 알 수 X
• 어디서 누가 했는 지 알 수 X
• 의미 없는 req를 모두 수신 (Dos 공격 방지 불가능)
  

보안 방법

• SSL이 제공하는 상대 확인 증명서 사용
  
  신뢰 가능한 제 3자 기관에서 발행되어 서버와 client 실재 증명
  
  통신 상대가 내가 통신하고자 하는 서버임을 보기 때문에 이용자는 개인 정보 누설 위험 낮음
  
  client : 본인 확인, 웹사이트 인증에 활용 가능
  

문제점 (3) : 완전성 증명 불가능해 변조 가능

• 수신 내용과 송신 측이 받은 내용의 일치 보장 불가능
• 중간자 공격 발생 여부 알 수 X

중간자 공격 : 공격자가 도중에 req, res를 뺏어 변조하는 성격

보안 방법

• MDS, SHA-1 등 해시값 확인, 파일 디지털 서명 확인 -> 확실 X
• https 사용

HTTPS

• HTTP 통신이 사용하는 소켓 부분을 SSL 또는 TLS 프로토콜로 대체
  
  http : TCP와 소켓 직접 통신
  
  https : http가 SSL과 통신하고 SSL이 TCP와 통신함
  
• 공개키를 공개키 암호화 방식으로 교환한 다음부터 통신은 공동키 암호를 사용하는 방식

5. DNS Round Rin 방식

문제점

• 서버 수만큼 공인 IP 주소 필요
  
  부하 분산 위해 서버 수를 늘릴 경우 그만큼 필요한 공인 IP 늘어감
  
• 균등하게 분산되지 않음
  
  스마트폰 접속 :
  
  캐리어 게이트웨이 프록시 거침.
  
  프록시에 이름변환 결과 캐싱되어 같은 프록시 경유 시 같은 서버 접속함
  
  PC 웹브라우저 접속 :
  
  DNS 질의 결과 캐싱하여 균등하게 부하 분산 X
• 서버가 다운되어도 확인 불가
  
  DNS 서버는 상황에 따른 질의 제어 불가능
  
  상황 감지가 불가능해 서버 다운을 검출해내지 못하고 유저들에게 제공함

Weighted round robin (WRR)

각각의 웹 서버에 가중치를 가미해서 분산 비율을 변경한다. 물론 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다.

Least connection

접속 클라이언트 수가 가장 적은 서버를 선택한다. 로드밸런서에서 실시간으로 connection 수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다.