HTTP의 GET과 POST 비교
HTTP(HyperText Transfer Protocol)
서버와 클라이언트가 인터넷상에서 데이터를 주고 받기 위한 프로토콜 입니다.
GET과 POST
HTTP의 메서드로 서버에 무언가를 요청할 때 사용하는 방식입니다.
GET
클라이언트에서 서버로 어떠한 리소스로부터 정보를 요청하기 위해 사용되는 메서드이다.
POST
리소스를 생성/업데이트하기 위해 서버에 데이터를 보내는 데 사용됩니다.
GET과 POST의 차이
GET 방식은 요청하는 데이터가 HTTP Request Message의 Header부분에 url에 담겨 전송되는데, url상에 ? 뒤에 데이터가 붙어서 요청을 보내게 됩니다. 데이터가 url에 담겨서 가기 때문에 데이터 크기가 제한적입니다. 또, 보안이 필요한 데이터를 전송하는 경우 url에 그대로 노출되어 전송되기 때문에, 보안면에서 좋지 않습니다. (ex. password)
POST 방식의 request는 HTTP Request Message의 Body 부분에 데이터가 담겨서 전송됩니다. 전송할 수 있는 데이터의 크기가 GET 방식보다 크고 보안면에서 낫습니다.
GET은 서버에서 어떤 데이터를 가져와서 보여주는 용도에 사용되고, 서버의 값이나 상태 등을 변경하지 않습니다. 반면에 POST는 서버의 값이나 상태를 변경하거나 추가하기 위해서 사용됩니다.
GET방식의 요청은 브라우저에서 Caching을 할 수 있습니다. Cache-Control이라는 HTTP 헤더 특성에 의해 제어됩니다. 따라서, GET방식으로 캐싱기능을 이용해서 요청한다면 기존에 caching 되었던 데이터가 응답될 가능성이 존재합니다.
TCP/IP(Transmission Control/Internet Protocol)
TCP/IP
패킷 통신 방식의 전송 제어 프로토콜(TCP)와 인터넷 프로토콜(IP)로 이루어져 있습니다. TCP는 IP 위에서 동작하는 프로토콜이고, HTTP, FTP, SMPT 등 TCP를 기반으로 하는 애플리케이션 프로토콜들도 IP 위에서 동작하기 때문에 묶어서 TCP/IP로 부르기도 합니다.
IP Address
인터넷에 연결되어 있는 모든 장치들(컴퓨터, 서버 장비, 스마트폰 등)을 식별하기 위해 부여되는 고유 주소이다.
IP
PORT
IP 내에서 프로세스를 구분하기 위해 사용하는 번호입니다.
Packet, Frame, Segment
모두 네트워크를 오가는 데이터의 단위이지만 어떤 OSI 계층에서 캡슐화된 것이냐에 따라 부르는 명칭이 달라집니다.
- 세그먼트: 전송 계층에서 전송되는 단위입니다.
- 패킷: 네트워크 계층에서 전송되는 단위입니다.
- 프레임: 데이터 링크 계층에서 전송되는 단위입니다.
랜카드
네트워크 안에서 컴퓨터간의 통신을 할 때 사용하는 장비 중 하나로 대체적으로 메인보드에 내장되어 있습니다.
3-way-handshake
데이터를 전송하기 전 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정입니다.
- 클라이언트는 서버에 접속을 요청하는 SYN 패킷을 보냅니다. 이때 임의의 랜덤 숫자를 일련번호로 포함해서 보냅니다.
- 서버가 SYN 패킷을 받고 클라이언트에게 요청을 수락한다는 ACK와 SYN가 설정된 패킷을 발송합니다. 이때 클라이언트에게 받은 패킷의 일련번호 x를 확인해서 Acknowledgment number를 x+1로 설정하고, 서버 측 일련번호 y를 생성해서 포함시킵니다.
- 클라이언트는 ACK와 SYN 패킷을 받아서 일련번호 y를 확인해 Acknowledgment number를 y+1로 설정한 ACK 패킷을 서버로 보내면 연결이 성립됩니다.
단순히 응답을 주고받는데 2-way Handshake면 충분해보이지 않는가? 왜 3-way 일까?
TCP 통신은 양방향성 connection 입니다. 클라이언트가 서버에게 존재를 알리고 패킷을 보낼 수 있다는 것을 증명하듯이, 서버에서도 클라이언트에게 존재를 알리고 패킷을 보낼 수 있다는 신호를 보내야 합니다. 그렇기 때문에 2-way handshake로는 부족합니다.
4-way-handshake
상대방 컴퓨터와 연결을 해제하는 과정입니다.
- 클라이언트는 서버에게 연결을 종료한다는 FIN 패킷을 보냅니다.
- 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보냅니다. 이때 모든 데이터를 보낼 때까지 잠깐 기다립니다. (CLOSE_WAIT 상태)
- 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 패킷을 클라이언트에게 보냅니다.
- 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보냅니다.
- 서버는 ACK를 받은 이후 소켓을 닫습니다.
- 클라이언트는 아직 서버로부터 받지 못한 데이터가 있을 것을 대비해 일정 시간 동안 세션을 남겨 놓고 남은 패킷을 기다리는 TIME_WAIT 과정을 거치고 이 시간이 끝나면 클라이언트도 소켓을 닫습니다.
TIME_WAIT 상태로 대기하는 이유는 세션 종료후, 혹시나 네트워크에 아직 라이브 패킷이 존재할수도 있기 때문입니다.
TCP 제어 플래그(TCP Control Flag)
TCP 헤더에는 6Bit의 Control Flag가 있고, URG, ACK, PSH, RST, SYN, FIN 순서로 되어 있습니다. 해당 위치의 비트가 1이면 해당 패킷이 어떠한 내용을 담고 있는 패킷인지를 나타냅니다.
- URN(Urgent pointer): 긴급한 패킷으로 우선 처리합니다. 이 플래그가 1로 설정되면 순서에 관계없이 먼저 전달됩니다.
- ACK(Acknowledgement): 요청에 대한 응답을 의미합니다. TCP가 연결되면 이 플래그는 항상 1로 설정됩니다.
- PSH(Push): 데이터 전송을 알리는 플래그입니다.
- RST(Reset): 연결을 재설정합니다. 플래그가 1로 설정됐다면 TCP 통신 도중에 강제로 연결을 종료합니다.
- SYN(Synchronized): 연결 요청을 위한 플래그입니다.
- Fin(Finish): 세션 연결을 종료할 때 사용하는 플래그입니다.
Sequence Number(일련번호)
송신 측에서 수신 측에 이 데이터가 몇 번째 데이터인지 알려주는 역할을 합니다.
Sequence Number가 랜덤으로 생성되는 이유
초기 sequence number를 ISN이라고 합니다. Connection을 맺을 때 사용하는 포트(port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용됩니다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재합니다. 서버 측에서는 패킷의 일련번호를 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 number가 전송된다면 이전의 connection으로부터 오는 패킷으로 인식할 수 있습니다. 이러한 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정합니다.
Acknowledgement Number(확인 응답 번호)
수신 측이 몇 번째 데이터를 수신했는지 송신 측에 알려주는 역할을 합니다.
TCP와 UDP 비교
UDP(User Datagram Protocol: 사용자 데이터그램 프로토콜)
데이터를 데이터그램 단위로 처리하는 프로토콜 입니다. 데이터그램이란 독립적인 관계를 가지는 패킷이라는 뜻입니다.
UDP는 비연결형 서비스로 연결을 설정하고 해제하는 과정이 존재하지 않고, 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않습니다. 그렇기 때문에 데이터의 처리가 TCP 보다 빠르다는 장점이 있지만 신뢰성이 낮습니다.
UDP를 사용한 것들에는 DNS가 있습니다. 어떤 호스트 네임의 IP 주소를 찾을 필요가 있는 프로그램은, DNS 서버로 호스트 네임을 포함한 UDP 패킷을 보냅니다. 이 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답합니다. DNS 서버는 항상 많은 클라이언트를 수용하기 때문에 신뢰성 보다는 속도가 더 중요하고, 클라이언트와 연결 상태를 유지 할 필요가 없기 때문에 UDP를 사용합니다.
DNS
도메인 네임을 IP 주소로 변환해주는 서버입니다.
TCP
인터넷상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜 입니다.
대부분의 인터넷 응용 분야들은 신뢰성과 순차적인 전달을 필요로 합니다. UDP로는 이를 만족시킬 수 없으므로 다른 프로토콜이 필요하여 탄생한 것이 TCP 입니다. TCP는 3-way-handshake 연결 설정을 통해 신뢰성 있는 데이터를 전송할 수 있습니다. (Sequence Number, Ack Number를 통한 신뢰성 보장)
모든 TCP 연결은 전이중(full-duplex), 점대점(point to point) 방식입니다. 전이중이란 전송이 양방향으로 동시에 이루어질 수 있는 것을 의미하고 점대점이란 서버와 클라이언트는 1대1로 연결되어 있음을 의미합니다. TCP는 멀티캐스팅이나 브로드캐스팅을 지원하지 않습니다.
멀티캐스트(multicast)
한 번의 송신으로 메시지나 정보를 목표한 여러 호스트에 동시에 전송하는 것을 말합니다. 데이터를 수신 받기를 원하는 특정한 호스트들에게만 전송이 가능합니다. (스위치나 라우터가 이 기능을 지원해 주어야 한다.)
브로드캐스팅(broadcasting)
송신 호스트가 전송한 데이터가 네트워크에 연결된 모든 호스트들에게 본인들의 의사와는 상관없이 전송하는 방식을 의미합니다.
스위치(Switch)
네트워크 회선과 서버 컴퓨터를 연결하는 네트워크 장비입니다.
라우터(Router)
스위치들을 서로 연결하여 네트워크 간 최적 라우팅 경로를 설정하고, 설정된 경로를 따라 트래픽을 전달하는 역할을 합니다.
HTTP와 HTTPS
HTTP의 문제점
- HTTP는 평문 통신이기 때문에 도청이 가능합니다.
- 통신 상대를 확인하지 않기 때문에 위장이 가능합니다.
- 완전성을 증명할 수 없기 때문에 변조가 가능합니다.
위 세 가지는 다른 암호화하지 않은 프로토콜에도 공통되는 문제점들입니다.
TCP/IP는 도청 가능한 네트워크입니다.
TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있습니다. 패킷을 수집하는 것만으로 도청할 수 있습니다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 합니다.
보완방법
- SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)라는 다른 프로토콜과 조합함으로써 HTTP의 통신 내용을 암호화할 수 있습니다.
- HTTP 메시지에 포함되는 콘텐츠만 암호화 하는 것입니다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요합니다.
통신 상대를 확인하지 않기 때문에 위장이 가능합니다.
HTTP 통신에는 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 요청을 보낼 수 있고, 상대가 누구든지 응답을 반환합니다.
보완방법
SSL로 상대를 확인할 수 있습니다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있습니다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행됩니다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 됩니다.
완전성을 증명할 수 없기 때문에 변조가 가능합니다.
완전성이란 정보의 정확성을 의미합니다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것입니다. 요청이나 응답이 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수가 없습니다. 이와 같이 공격자가 도중에 요청이나 응답을 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부릅니다.
보완방법
MD5, SHA-1 등 해시함수를 이용하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니기 때문에 확실히 방지하기 위해서는 HTTPS를 사용해야 합니다.
=> 평문과 평문을 암호화한 값을 보내고, 받은 쪽에서 암호화된 값을 복호화 하고 평문과 비교해 같은지 다른지를 비교해 변조의 유무를 확인하는 방법입니다.
HTTPS
HTTP에 암호화와 인증, 그리고 정보의 완정성 보호를 더한 프로토콜입니다.
HTTP 통신하는 소켓 부분을 SSL/TLS 라는 프로토콜로 대체한 것입니다. SSL을 사용한 HTTPS는 암호화와 증명서, 안정성 보호를 이용할 수 있습니다.
HTTPS의 SSL에서는 대칭키 암호화 방식과 비대칭키(공개키) 암호화 방식을 혼합한 하이브리드 암호 시스템을 이용합니다. 대칭키를 비대칭키 암호화 방식으로 공유하고 그 다음부터의 통신은 대칭키 암호를 사용하는 방식입니다.
모든 웹 페이지에서 HTTPS를 사용해도 될까?
평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구합니다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 됩니다.
하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않습니다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재에는 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있습니다.
SSL/TLS
웹 서버와 클라이언트의 통신 암호화 프로토콜입니다.
DNS round robin 방식
DNS(Domain Name System)
도메인 네임을 IP 주소로 바꾸는 역할을 합니다.
DNS Round Robin 방식의 문제점
- 서버의 수 만큼 공인 IP 주소가 필요합니다.
부하 분산을 위해 서버의 개수를 늘리기 위해서는 그 만큼의 공인 IP가 필요합니다. - 균등하게 분산되지 않습니다.
스마트폰의 접속은 캐리어 게이트웨이 라고 하는 프록시 서버를 경유합니다. 프록시 서버에서는 이름변환 결과가 일정 시간 동안 캐싱 되므로 같은 프록시 서버를 경유하는 접속은 항상 같은 서버로 접속됩니다. 또, PC 용 웹 브라우저도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하 분산 되지 않습니다. DNS 레코드의 TTL(Time To Live) 값을 짧게 설정함으로써 어느 정도 해소가 되지만, TTL에 따라 캐시를 해제하는 것은 아니므로 반드시 주의가 필요합니다. - 서버가 다운되어도 확인 불가합니다.
DNS 서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의 결과를 제어할 수 없습니다. 웹 서버의 부하가 높아서 응답이 느려지거나 접속 수가 꽉 차서 접속을 처리할 수 없는 상황인지를 전혀 감지할 수 없기 때문에 어떤 원인으로 다운되더라도 이를 검출하지 못하고 유저들에게 제공합니다. 이때문에 유저들은 간혹 다운된 서버로 연결이 되기도 합니다.
프록시 서버
클라이언트가 자신을 거쳐 다른 네트워크에 접속할 수 있도록 중간에서 대리해주는 서버를 말합니다.
TTL(Time To Live: 타임 투 리브)
컴퓨터나 네트워크에서 데이터의 유효 기간을 나타냅니다.
해소 스케줄링 알고리즘
Weighted round robin (WRR)
각각의 웹 서버에 가중치를 부여해서 분산 비율을 변경합니다. 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋습니다.
Least connection
접속 클라이언트 수가 가장 적은 서버를 선택합니다. 로드밸런서에서 실시간으로 연결 수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요합니다.
로드밸런서(Load Balancer)
서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 또는 기술을 의미합니다.
