안녕하세요 :) 소들입니다
오늘 공부할 내용은 HTTP 통신에 관련해서..
도대체 무엇인지에 대해....ㅎ
흐흐 🌝🌝
HTTP/HTTPS의 차이점은 TLS 할 떄
자세하게 다뤘지만! 이번 챕터에서 다시 다뤄보려 합니당!!
모든 포스팅은 편의 말투로 합니다~!!
1. Socket vs HTTP
자, 먼저 Server와 통신 방법 중 가장 대표주자인
Socket과 HTTP에 대해서 비교를 하며 설명할 것임
Socket 통신
Socket 통신은 한번 연결에 성공하면, 연결이 계속 유지됨!!!
(임의로 끊거나, 네트워크 사정 상 끊기는 것이 아니라면)
따라서, 연속적(실시간)으로 데이터를 받아야 하는 경우인
실시간 스트리밍, 채팅 같은 서비스에 사용되는 것임
또한 양방향 통신이라,
보통 Client가 Server에게 데이터를 요청하지만,
반대로 Server가 Client에게 데이터를 요청할 수도 있음
이것이 Socket 통신 :)
HTTP 통신
HTTP 통신은 Client에서 데이터가 필요할 때마다
Server에게 요청하고, Server는 그 데이터를 응답하고
그리고 바로 연결이 종료 되는 방식임!!
우리가 지금 보고있는 이 티스토리 페이지 또한
처음 로드될 때 HTTP 통신으로 Server로부터 데이터를 받아와 보여주는 것이고,
바로 연결이 끊겼을 것임!
근데 여기서 내가 다른 페이지를 가거나, 화면을 새로고침 하면
그럼 또 HTTP 통신으로 Server로부터 데이터를 받아와 보여주고, 바로 연결을 끊길 것임
이처럼 HTTP 통신은 단방향 통신이라,
Client만 Server에게 요청할 수 있고,
Server는 Client에게 요청할 수 없음!!!
보통 실시간으로 서비스해야 하는 경우를 제외하곤 이 HTTP 통신을 사용하는데,
이 HTTP 통신을 할 경우 좋은 점은
Server의 부하를 줄여줌!!
계속 연결을 맺는 게 아닌, 원하는 요청에 대한 데이터만 던져주고 끊기므로,
Server가 다른 접속들도 원활히 처리할 수 있어짐!
이것이 HTTP 통신 :)
2. HTTP 메시지
자, 우리가 HTTP 통신을 한다고 가정 해보셈
새로 고침을 눌러서 이 티스토리 페이지를 다시 로드 하려면,
Client가 Server에 데이터를 요청해야 할 거잖음?
이처럼, Client가 Server에 무엇인가를 '요청'할 때, 그냥 막 하면 안되고,
일정한 형식을 갖춰서 텍스트 기반의 메세지로 변환해서 전달해야 함
이때, 이 메세지의 형식을 바로
HTTP 메시지라고 함 :)
보통 이 HTTP 메시지를 만들고 변환하는 과정은 대부분 이 티스토리 같은 브라우저 몫인데,
iOS 앱의 경우엔 HTTP 메시지를 직접 만들어서 전송해주어야 함..
(물론 잘 짜여진 라이브러리를 써도 되지만, 그래도 개념은 알고 갑시다:D)
근데 위에서도 말했듯 HTTP 메시지는 '텍스트' 기반이기 때문에,
구조가 어렵지 않고 쉬움 :) 같이 알아보ㅏ보잣
2-1. HTTP 메시지 구조
HTTP 메시지는 크게
요청 메시지
응답 메시지
두 가지로 나눌 수 있음!!!!
이 두 메세지 모두 다음과 같이
라인 - 헤더 - 바디
세 부분으로 구성됨!!
라인
메시지의 가장 기본 내용인 응답/요청 여부, 메시지 전송 방식, 상태 등이 작성됨
매우 정형화되어 있어, 무조건 한 줄로만 작성됨
|
POST /userAccount/login HTTP/1.1
|
보통 이런 식인데,
가장 처음에 POST/GET 등의 전송 메서드를 정의하며 시작함
뒤이어 요청 내용에 대한 경로가 오고,
마지막으로 요청 형식에 대한 버전 정보가 옴
이렇게 한 줄이 바로 라인에 해당함!!!
헤더
메시지 본문에 대한 메타 정보가 들어가는 부분으로,
필요한 만큼 여러 줄로 작성됨
길이가 유동적이므로, 바디와 구분을 짓기 위해 한 줄의 공백이 삽입됨
(HTTP 메시지에서 나타나는 첫 번째 한 줄의 공백이 헤더와 바디를 구분하는 경계선임)
|
Host: swiftapi.rubypaper.co.kr:2029.
Content-Type: application/json
|
Host란 Key에는, 도메인 및 포트번호가 Value로 오고,
Content-Type이란 Key에는 메시지 바디의 타입을 나타내는데,
우리가 사용하는 JSON은 application/json 이라고 설정해주면 됨
바디
실제로 보내고자 하는 메시지 본문 내용이 들어가는 부분으로,
길이가 유동적임
바디에 들어가는 메시지 형식은, 헤더의 Content-Type에서 설정한 Type과 일치해야 함!!
우린 JSON으로 설정했기 때문에
|
{ "name" : "Sodeul" }
|
머 이런 식으로 가야 함!!!
자, 근데 라인 처음에 정의하는 전송 메서드에는
크게 전송 방식이 2가지 있는데, 이에 따라 이 HTTP 메시지의 형태가 좀 바뀜!!!
(물론 좀이따 설명할 RestAPI는 더 다양함. 근데 일반 웹브라우저는 2가지만 씀)
2-2. POST / GET
우리가 이렇게 HTTP 메시지를 만들 때,
라인 첫번 째에 POST니 GET이니 전송 메서드를 쓴다고 했잖음??
이때, 이 전송 메서드는 일반 웹브라우저에선 크게 2가지가 많이 쓰이는데,
이 둘의 특징을 봐보겠음
POST
|
POST /userAccount/login HTTP/1.1 // (1) 라인
Host: swiftapi.rubypaper.co.kr:2029. // (2) 헤더
Content-Type: application/x-www-form-urlencoded // (2) 헤더
account=swift%40swift.com&passwd=1234&grant_type=password // (3) 바디
|
우리가 위에서 공부한 게 사실 POST 방식임
헤더에 Content Type을 명시하고, 바디에 Content Type에 맞는 데이터를 넣는 것!!
HTTP 메시지가 달라지는 것은 POST가 아니라 바로 GET임
(Content-Type이 바꼈지만, 형식만 안다면 문제 없다고 봄!!)
GET
자 GET에서는 위 POST 메시지가 어떻게 바뀌냐면
|
GET /userAccount/login?account=swift@swift.com&passwd=1234&grant_type=password HTTP/1.1 // (1) 라인
Host: swiftapi.rubypaper.co.kr:2029 // (2) 헤더
Content-Type: no-cache // (2) 헤더
|
이런 식으로 바뀜!!! 눈치 챘을랑가 👀
라인이 엄청 길어지고, 바디가 사라짐!!!!!!11
더 자세히 보면,
바디가 사라졌지만 바디에 있던 내용이 라인의 경로 뒤에 "?" 와 함께 합쳐져 버림
또한 헤더의 Content-Type도 no-cache로 바뀜
자, 이처럼 GET에서는 메시지 본문을 사용하지 않고,
본문의 파라미터를 모두 URL 뒤에 연결해서 전달해버림
이렇게 연결되는 파라미터를 쿼리 스트링(Query String) 이라고 함!!
쨌든, 본문을 사용하지 않기 때문에, 헤더의 Content-Type이 사용되지 않음
URL 뒤에 쿼리 스트링만 연결하면 돼서 간결하게 정보를 전달할 수 있는 장점이 있지만,
URL 경로의 허용범위가 1024Byte이기 때문에 긴 값은 전송할 수 없음
따라서 데이터를 '전송' 할 때 보다, 필요한 정보를 '요청' 할 때 주로 사용됨!!!
그럼 언제 POST를 쓰고, 언제 GET을 쓸가여?
POST의 경우 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있을 때 사용함
서버의 상태나 데이터를 변경시킬 때 사용하는데, 예를 들면
게시글을 쓰고, 삭제하는 것은 데이터가 변경되는 것이므로 POST로 요청을 해야함
(물론 POST, PUT, DELETE가 있지만)
GET의 경우 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아와할 때 사용함
POST와 반대로 GET은 서버의 상태나 데이터를 변경시키지 않을 때 사용하는데,
조회할 때 주로 사용함! 게시글을 조회 한다든지
이처럼 서버 데이터가 변경되지 않는 것은 GET으로 요청을 해야함
일반적인 브라우저에선, POST / GET이 많이 사용되긴 하는데,
PUT, DELETE, 같은 전송 메서드 등도 있음!! (나중에 정리함)
3. RESTful API
자.. 드디어 하나 더 나와따
RESTful... 뭐하는 놈이냐
먼저, REST는 어떠한 네트워크 프로토콜이 아님!!!
HTTP에서 데이터를 주고 받을 때,
간단히 주고 받자!! 해서 정의된 간단한 형식의 인터페이스
를 말함!!!
이러한 REST 구조를 따라 구현된 시스템을 바로 RESTful 이라고 부름 ㅎㅎ
매우 쉽고 간단하게 구현할 수 있어서, 대부분 모바일 통신은 Restful 기반임!!
이때, RESTful 기반으로 서버에서 요청과 응답을 주고받을 수 있도록 정의된 형식을
바로 RESTful API라고 부름!!
이 REST 형식이 궁금하다면,
REST API 제대로 알고 사용하기 : TOAST Meetup
REST API 제대로 알고 사용하기
meetup.toast.com
여기에 잘 나와 있음 :)
(URI, 자원 정보 규칙 등)
근데,
이 RESTful API에서 주고받는 내용들은 모두 HTTP 메시지의 본문에 담겨서 전달되는데,
RESTful API는 메시지 본문을 JSON 형태로 구성해서 보냄!!
따라서 RESTful API로 통신하기 위해선 JSON 데이터 형식을 잘 알아야함
와우 일단 RESTful에 대해 더 자세하게 들어가진 않고, 여기까지 말하겠음
(JSON을 잘 모르신다면 이전 포스팅을 보고 오시오...)
4. HTTP / HTTPS
그래 HTTP 통신이 뭔 줄은 알겠어
근데 HTTPS는 뭐임??
😱
이전 포스팅 긁어올래
.
.
-내 포 스 팅 발 췌-
이번엔 HTTP와 HTTPS 차이점에 대해 알아볼 거예요.
S하나 붙었지만 왠지 이 s가 Secure의 약자일 거 같은 느낌이 오시나요.
먼저, HTTP 는 다음과 같이 암호화 되지 않은 평문으로 데이터를 전송해요.
이런 식으로!
따라서 누군가 패킷을 훔쳐보는 스니핑(Sniffing) 👀공격에 취약하죠.
HTTP 통신에선 Wire Shark를 통해 패킷을 확인하면 내 주민번호가 그대로 서버로 전송되는 것을 볼 수 있답니다?
누가 패킷 훔쳐보면 제 주민번호 그대로 털리는 거예요 :D
때문에, 서버와 클라이언트 간 데이터를 보호하기 위해선 패킷을 암호화 한 뒤 전송해야 해요.
이것이 바로 HTTPS 입니다.
이때 사용하는 보안 인증(암호화 + 서버인증 등)이 TLS(SSL)입니다.
즉,
HTTPS는 TLS 프로토콜 위에서 돌아가는 HTTP 프로토콜
입니다. 그냥 쉽게 말해
HTTP 통신에서 보안을 추가한 것이 HTTPS 구나!
정도만 알고 가시면 돼요 :)
참고로 애플은 2016년 10월 경부터 앱스토어에 등록되는 모든 앱은 HTTPS 프로토콜을 이용한 네트워크 통신만 허용하고 있어요. 따라서 서버와 연동하는 앱이라면 서버에서 미리 인증서를 발급받아 준비해두어야 해요.
.
.
- 발 췌 끝 -
저 옛날엔 되게 친절했네염 ㅎㅎ;;;;
쨌든 포스팅 끝 피드백 잘못된 내용 환영
참고한 블로그 출처
hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/
GET과 POST의 차이
HTTP HTTP는 웹상에서 클라이언트와 서버 간에 요청/응답으로 데이터를 주고 받을 수 있는 프로토콜입니다. 클라이언트가 HTTP 프로토콜을 통해 서버에게 요청을 보내면 서버는 요청에 맞는 응답을
hongsii.github.io
'iOS > iOS' 카테고리의 다른 글
| iOS) 런 루프(RunLoop) 이해하기 (13) | 2020.12.03 |
|---|---|
| iOS) GCD (Grand Central Dispatch) (6) | 2020.12.02 |
| iOS) Sync vs Async / Serial vs Concurrent (16) | 2020.12.01 |
| iOS) 프로세스(Process) vs 쓰레드(Thread) (8) | 2020.12.01 |
| iOS) 메모리 저장 방식 - Big Endian / Little Endian (0) | 2020.11.28 |
