HTTP : GET과 POST 비교
- 공통점 : 서버에 무엇인가를 요청할 때 사용하는 방식
GET
- Header부분의 URL에 담겨서 전송 - URL상의 ?뒤에 데이터가 붙어서 request를 보낸다.
- 데이터 크기 제한적
- URL에 노출되기 때문에 보안없음
- 데이터를 가져온다 = 서버에서 데이터를 가져와서 보여준다거나 하는 용도, 서버의 데이터를 변경하지 않는다
POST
- body부분에 담겨서 전송
- 데이터크기의 제한이 없고, GET보다 보안적으로 낫다[암호화하지 않는 이상 크게 차이없다]
- 서버의 값이나 상태를 변경하기 위해서 또는 추가하기 위해서 사용된다.
TCP vs UDP
TCP
- 신뢰성, 순차적인 전달
- 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.
- 송신자와 수진자 모두 소켓이라는 종단점을 생성함으로써 이루어진다.
- 연결설정 : 3 handshake
- 전이중(full duplex) : 양방향으로 통신 가능
- 점대점(point to point) : 각 연결이 정확히 2개의 종다점을 가지고 있음을 의미
UDP
- 비연결형 프로토콜
- 흐름제어, 오류제어, 손상된 세그먼트의 수신에 대한 재전송이 없다.
- 포트들을 사용하여 IP프로토콜에 인터페이스를 제공하는 것
HTTP / HTTPS
HTTP의 문제점 = 암호화하지 않는 모든 프로토콜의 문제점
- 평문 통신이기 때문에 도청이 가능
=> TCP/IP는 도청이 가능한 네트워크이다.보안 방법
통신 자체를 SSL 또는 TLS 등 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. => SSL + HTTP = HTTPS [ HTTP over SSL ]
HTTP 메시지에 포함되는 콘텐츠만 암호화한다. 받는 측에서는 해독하여 출력하는 과정이 필요하다.
- 통신 상대를 확인하지 않기 때문에 위장이 가능
문제점
- 답변을 준 서버가 정확한 서버인지 알 수 없다.
- 답변이 보낸 곳이 정확한 클라이언트인지 알 수 없다.
- 통신하고 잇는 상태가 접근이 허가된 상대인지 확인할 수 없다
- 어디서 보냈는지 알수 없다
- 의미없는 request도 수신하다 = DoS 공격을 방지할 수 없다
보안방법
SSL : 상대를 증명하는 수단인 증명서를 제공
- 완전성을 증명할 수 없기 때문에 변조가 가능
=>정보의 정확성을 신뢰할 수 없다 = Man-in-the-Middle 공격이 가능보안방법
- MDS, SHA-1등의 해시값을 확인하는 방법
- 파일의 디지털 서명을 확인하는 방법
- HTTPS 사용 : 가장 확실한 방법
HTTPS = HTTP + SSL/TLS
원래는 HTTP가 바로 TCP와 통신했지만, HTTPS는 HTTP는 SSL과 통신하고 SSL이 TCP와 통신한다. 그러므로 SSL의 암호화, 증명서 등을 활용하여 안전성을 확보할 수 있다.
모든 페이지에서 HTTPS를 사용하지 않는 이유
통신할 때마다 암호화하면 많은 리소스를 소비하기 때문에 서버 한대당 처리할 수 이쓴 리퀘스트의 수가 줄어든다.
=> 민감한 정보에만 HTTPS를 사용하여 암호화통신을 사용
DNS Round Robin 방식의 문제점
- 서버의 수만큼 ip주소가 필요하다. => 부하분산을 위해 서버의 대수를 늘리기 위해서는 그만큼의 공인 ip가 필요하다
- 균등하게 분산되지 않는다. => 문제가 될 수 있다.
- DNS 서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의 결과를 제어할 수 없다.
해결방법
weigthed round robin : WRR
각각의 웹 서버에 가중치를 가미해서 분산 비율을 변경한다. 물론 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다
Last connection
접속 클라이언트 수가 가장적은 서버를 선택한다. 로드밸런서에서 실시간으로 connection수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다.
웹 통신의 큰 흐름
in 브라우저
- url에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사
- 조사된 의미에 따라 HTTP Request 메시지를 만든다
- 만들어진 메시지를 웹 서버로 전송한다. => 브라우저가 직접하는 것은 아니다. 메시지를 네트워크에 송출하는 기능이 없으므로 so에 의뢰하여 메시지를 전달
in 프로토콜 스택, LAN 어댑터
1.프로토콜 스택 [운영체제에 내장된 네트워크 제어용 소프트웨어]이 브라우저로부터 메시지를 받는다 .
2. 브라우저로부터 받는 메시지를 패킷 속에 저장한다
3. 그리고 수신처 주소 등의 제어정보를 덧붙인다
4. 그런 다음, 패킷을 LAN 어댑터에 넘긴다.
5. LAN 어댑터는 패킷을 전기신호로 변환하시킨다.
6. 신호를 LAN 케이블에 송출시킨다.
프로토콜 스택은 통신 중 오류가 발생했을 때, 이 제어 정보를 사용하여 고쳐보내거나, 각종 상황을 조절하는 등 다양한 역할을 하게 된다.
in 허브, 스위치, 라우터
- LAN 어댑터가 송신한 패킷은 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착한다.
- 라우터는 패킷을 프로바이터[통신사]에게 전달한다
- 인터넷으로 들어가게 된다.
in 액세스 회선, 프로바이더
- 패킷은 이너텐ㅅ의 입구에 잇는 액세스 회선[통신회선]에 의해 POP[Point Of Presence:통신사용라우터]까지 운반된다.
2.POP를 거쳐 인터넷의 핵심부로 들어가게 된다- 수 많은 고속라우터들 사이로 패킷이 목적지를 향해 흘러가게 된다.
in 방화벽, 캐시서버
- 패킷은 인터넷 핵심부를 통과하여 웹 서버측의 LAN에 도착한다
- 기다리고 있던 방화벽이 도착한 패킷을 검사한다
- 패킷이 웹 서버까지 가야하는지 가지 않아도 되는지를 판단하는 캐시서버가 존재한다.
in 웹 서버
- 패킷이 물리적인 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘긴다
- 메시지를 받은 웹 서버 애플리케이션은 요청 메시지를 따른 데이터를 응답 메시지에 넣어 클라이언트로 회송한다
- 왔던 방식대로 응답 메시지가 클라이언트에게 전달된다
