채니의 mimimimamimimo 블로그

what? http,https 둘다 인터넷 통신에서 앱계층의 프로토콜이다.

웹 브라우저를 사용해서 통신하는데, 클라이언트와 서버의 위치를 URL로 표시한다.

*HTTP: hypertext transfer protocol

*URL: uniform resource locator

여기서 말하는 resource(자원)은 웹사이트(html) 뿐만이 아니라 네트워크 상에 연결된 다양한 자원들을 포함한다. 

issue! HTTP는 이름처럼 텍스트를 주고 받으며 통신하기 때문에, 전송신호를 인터셉트하면 데이터가 유출될 수 있다.

보안성을 높여 이것을 막는 것이  HTTPS이다.

how? 사용자마다 다른 암호를 제공해서 구현한다. ->공개키 암호화 방식

why? HTTPS를 지원하는 서버에 요청(Request)을 하려면 공개키가 필요하다는 것을 알 수 있다.

여기서 개발자가 고려해야할 부분, 특성에 맞게 적절하게 쓰려면~~

1. 유출되면 위험한 데이터 통신이 필요할 때 쓴다. 

ex) 회원가입(위험O)/판매상품게시(위험X)

2.마케팅 적으로 유리하려면, 검색엔진이 https로 보안적용 된 것을 우선순위로 보여준다

3.CA 기업에 지불할 비용

4.비연결형의 경우 통신이 잠시 끊겼다가 재시작되면 다시 키로 인증을 받아야해서 부하가 생긴다

동작순서

what? 인터넷에서 데이터를 송수신하는 전송계층의 프로토콜이다.

where? 컴퓨터의 프로토콜 스택안에 TCP,UDP가 LAN카드(실제 케이블 신호 송수신)와 함께 있다.

*프로토콜 스택 

통신을 위한 규약의 집합이다. 내부에 메모리가 있고, 여기에 각 층의 제어정보를 기록한다. 이 메모리 영역이 소켓이다. 

즉, 소켓을 만든다는 것(앱층에 소켓 호출,ex 자바 소켓함수)은 이 메모리영역에 제어정보(IP,포트번호 등)를 추가하고 버퍼메모리를 준비하는 등의 작업을 하는 것이다. 

서비스 정의(HTTP,FTP,SMTP..)

데이터전송 신뢰성 보장(TCP.UDP)

패킷 전달 경로를 결정(IP)

패킷을 보내는 것 지원(과부하 안걸리게 조절 등)(이더넷)

유무선으로 데이터 송수신(IEEE)

-송신측 기기의 프로토콜 스택 동작 순서: 앱->...->물리 

-수신측 기기의 프로토콜 스택 동작 순서: 물리->...->앱

=>TCP가 제어정보를 기록한 헤더를 만들고, 이를 IP담당에 보내서 송신 의뢰를 한다. 그럼

IP에선 서버측 IP 담당부분에 전달하고 그 친구는 헤더를 TCP에 보낸다.TCP는 조사하고 소켓에 정보를 기록하고,

네트워크 상태를 진행중으로 바꾼 뒤 ACK를 돌려보낸다. //이전 포스팅 참고 

*UDP*

신뢰성을 보장하지 않음. 즉, 연결에 대한 사전 설정을 하지 않고, 일단 보낸다. 서버로부터의 응답이 손실되면 클라이언트는 TIMEOUT 되어 다시 보내는 방식이다.

->비연결형 프로토콜

->짧게 조회하는 DNS서버에 대한 조회, 성능 중요한 파일전송,스트리밍 서비스 등

->IP 데이터그램을 캡슐화 (user datagram protocol)

->속도 빠름

->헤더의 체크섬 등으로 최소한의 오류만 검출

->연결이 없어서 서버소켓과 클라이언트 소켓의 구분이 없다

->소켓 대신 ip를 기반으로 데이터를 전송한다

*TCP*

3-hand shake를 사용해서 연결하고, 4-hand shake로 해제하여 신뢰성을 보장함-> 메일 등 일반적인 앱 데이터 수신

->연결형 프로토콜(대부분 순차적인 데이터 송수신이 필요하기 때문에 UDP에서 발전된 것이다)

->송신자,수신자 모두 소켓을 생성해야한다(양방향 프로토콜)

->속도 느림

->손실된 경우 재전송 요청을 하기 때문에 스트리밍 서비스에 불리하다

동작원리:

가도되니?응 와도 돼. 간다~~!!

*서버는 Listener가 켜져 있는 상태로 대기, 클라이언트도 서버도 ACK를 받는 순간 established(연결성립) 된다는 점에 주의하자. 

SYN: 싱크로나이즈 넘버

ACK: 애크놀리지 넘버

what?

 전송 제어 프로토콜(TCP)에서 통신을 하는 장치간 서로 연결이 잘 되어있는지 확인하는 과정, 방법

 ex) 서버와 클라이언트 사이이에서 패킷을 전송할 때

why?

 TCP프로토콜의 목적은 데이터의 신뢰도가 중요할 때 사용하기 위해 만들어졌기 때문이다.

how?

 개발자가 할 수 있는 것은 이러한 특성을 파악하고 TCP와 UDP 중에서 적절한 통신 프로토콜을 선택하는 것이다.

 ex)음악 스트리밍 같은 경우 조금만 불안정해도 버퍼링이 사용자에게 불쾌감을 주므로 신뢰도가 덜 보장되더라도 UDP를 선택한다.

issue! syn flooding: 존재하지 않는 클라이언트 IP로 SYN 요청만 엄청 보내서 백로그를 가득 채워, 다른 클라이언트의 요청을 받지 못하게 하는 악의적인 행위가 있을 수 있다.

거시적으로 흐름을 이해하는 것은 중요하다. 그 요소들이 형태가 무엇인지, 소프트웨어인지 하드웨어인지, 동작원리 등 물리적인 관점에서 바라보는 것도 중요하다. 

HTTP: 웹상에서 클라이언트와 서버 간에 요청/응답으로 데이터를 주고 받을 수 있는 프로토콜.

클라이언트->서버(요청) , 클라이언트<-서버(응답) 일 때, 요청을 수행할 때 취해야하는 방식을 http메소드로 정하는 것이다.

GET: 가져오다, 서버로부터 정보를 조회하기 위해 설계된 메소드. 

how? 요청시 필요한 데이터를 쿼리스트링 형식으로 header에 담는다. 

쿼리스트링이란, URL의 끝에 ? 와 함께 키,값 쌍으로 파라미터를 붙여준 문자열이다.(&로 여러개 가능)

www.mimimimamimimo.com/resource?name=value1&name=value2  <==이게 바로 header!!

issue! 이미지 같은 정적 컨텐츠는 데이터 양이 크고, 변경된 일이 적기 때문에 동일한 요청이 발생했을 경우 서버로 요청을 보내지 않고 캐시된 데이터를 사용한다. 그래서 정적컨텐츠가 캐시돼 컨텐츠를 변경해도 바뀌지 않는 경우가 종종 발생한다. 

sql injection 발생가능!

when?  게시글을 조회하는 기능

POST: 게시하다, 서버의 정보를 수정하기 위해 설계된 메소드. 

how? 요청시 필요한 데이터를 body에 숨겨서 보낸다.

issue! GET보단 보안성이 있지만 그래도 크롬 개발자도구 등으로 요청 내용을 확인할 수 있으므로 민감한 데이터라면 암호화가 필요하다. 그리고, 요청 데이터의 타입을 헤더에서 표시해야한다. 그렇지 않으면 타입을 유추해야 하기 때문이다.

when? body는 길이의 제한이 없기 때문에 대용량 데이터를 넣어서 보낼 때 쓴다.

게시글을 생성하는 기능

즉. GET은 동일한 연산을 여러번 수행해도 동일한 결과가 나오고

POST는 동일한 연산이라도 다른 결과를 응답할 수 있다.

DELETE: 지우다, 00블로그를 지워달라

HEADER: 서버의 헤더만 읽어와 달라.

...그 외에도 다양한 http 메소드가 존재한다.

=>get,post,delete...등 메소드들이 동사의 역할을 한다. 이런 꼴을 취하는 것이 REST 구조!

=>브라우저의 주소창은 GET방식의 요청일뿐이다. POST방식을 사용해서 보내고 싶으면, body에 숨기는 작업이 필요하기 때문에 특정 도구가 필요하다(그거그거)

=>html 첫 줄에 get,post를 지정하는 부분이 있다.

*아이패드로 정리한 pdf 파일*