먼저 React Hooks의 useCallback과 useMemo부터 설명하겠습니다.
그 전에 알아둬야할게 있는데,
첫 번째로는 함수형 컴포넌트는 단지 jsx를 반환하는 순수 함수입니다.
그저 입력과 실행, 반환만이 있을 뿐입니다.
두 번째로는 컴포넌트가 렌더링 된다는것은 누군가가 그 함수를 호출하여서 실행한다는것이고,
함수가 실행될때마다 내부에 선언되어있던 표현식 변수 또 다른 함수는 다시 선언됩니다.
세 번째로 컴포넌트는 자신의 state가 변경되거나 부모에게서 받은 props가 변경되었을때마다 리 렌더링 되는것입니다.
(다음)
금방 말씀드렸다 싶이 컴포넌트는 렌더링 될 때마다 내부에 선언되어있던 표현식도 매번 다시
선언된다고 했는데요,
함수 컴포넌트 내부에서 어떠한 함수가 매번 렌더링 될때마다 다시 선언되는것은 좀 비효율적이고
메모리 낭비인듯 하죠?
이럴때 useCallback을 사용하는데, useCallback은 메모리제이션된 함수를 반환합니다.
함수를 굳이 매번 선언하기보다는 한번만, 아니면 지정된 값이 변경되었을때만 선언하고
재사용하기 위해서 useCallback을 사용합니다.
주로 이벤트 핸들러 함수나 API 요청하는 함수를 useCallback으로 사용합니다.
(다음)
사용방법은
useCallback 함수의 첫 번째 인자로 앞으로 사용할 함수를 전달합니다.
두 번째 인자는 종속성 배열로써, 지정한 값이 변경될때마다 다시 함수를 선언 시킵니다.
제가 느끼기에는 함수는 렌더링 되었을때 단 한번만 선언되면 좋을듯해서 예시는 빈 배열로 넣어뒀습니다.
useCallback은 예시처럼 간단한 함수를 저장하기 보다는 꽤나 복잡한 함수를 저장시키는게 적절합니다.
이러한 간단한 함수를 저장시키는것 보다 useCallback을 사용하는 메모리가 더 클 경우도 있고,
차이가 있다해도 효과는 미미하다고 합니다.
(다음)
다음은 useMemo를 설명드리겠습니다.
useMemo를 설명드리기 앞서 예시코드를 잠깐 설명드리겠습니다.
color와 movie를 state로 가지고있는 상위 컴포넌트에서는 onChangeHandler 함수로 인해 값이 변경됩니다.
변경된 값은 하위 컴포넌트로 두 state를 props로 넘겨주고
하위 컴포넌트는 이 값을 한국어로 변경시켜주는 함수를 이용해 props를 가공합니다.
(다음)
이 상황에서 첫 렌더링 되었을때는 두개의 props 값을 가공시키고
하나의 값만 변경되었을 때도 두개의 props 값이 가공됩니다.
굳이 이럴 필요없이 바뀐 값만 가공시키는것이 useMemo입니다.
(다음)
useMemo의 사용 방법은
마찬가지로 첫번째 인자에는 계산 함수를 넣고,
두번째 인자는 종속성 배열로써, 계산에 필요한 데이터를 넣어 해당 데이터가 변경 될 때마다 재 계산하도록 해줍니다.
다음과 같이 useMemo를 설정 해주고 color값만 바뀌었을때 movieGenreKor은 작동되지 않습니다.
이건 movie값이 바뀌지 않아 기억하고있는 값과 동일하기 때문에 굳이 계산을 실행하지 않는것입니다.
이것역시 간단한 계산보다는 복잡한 계산을 넣어주는게 적절하고 이유는 useCallback과 같은 맥락입니다.
(다음)
이제 http와 https의 차이점 입니다.
우선 http는 데이터를 주고 받기 위한 가장 기초적인 프로토콜로써 통신 규약으로 80번 포트를 사용합니다.
http는 stateless 무 상태성 프로토콜이며, 메소드 패쓰 버전 헤더스 바디 등으로 구성 되어 있습니다.
무 상태성이란 상태가 유지되지않는것으로 로그인상태나 장바구니등의 정보가 저장되지 않는다는것입니다.
(다음)
http의 구조는 요청과 응답이 동일합니다.
요청의 startLine은 말 그대로 요청의 첫 라인입니다.
여기서 구성되는 method는 get post put delete option등등이 있고
request target은 request가 전송되는 목표 uri
version은 말 그대로 사용되는 HTTP 버전입니다.
headers에는 요청이 전송되는 형식을 보내줍니다.
target의 host, (예를 들어서 google.com)
요청 보내는 클라이언트에 대한 정보를 담은 useAgent
해당 요청이 받을 수 있는 응답 accept
해당 요청이 끝난후에 클라이언트와 서버의 연결 유무를 지시하는 connection
요청을 보내는 body의 타입을 나타내는 content type등이 있습니다.
body는 요청의 실제 메세지/데이터를 담고 있으며 body가 없는 request도 있습니다. (예를들어서 get요청)
응답의 구조는 요청과 거의 같으며 startline에는 상태 코드와 상테 메세지가 있습니다.
(다음)
http의 문제점은 첫번째로 암호화 기능이 없어 중간자 공격에 취약하다는점이 있고,
통신하려는 사이트가 신뢰할 수 있는지 확인이 불가합니다.
따로 확인작업이 없기 때문에 다른 사이트가 통신하려는 사이트로 위장이 가능합니다.
예를들어서 네이버에 접속했는데 진짜로 찐 네이버인지 확인이 힘들다는겁니다.
마지막으로 통신 내용이 변경 가능하다는겁니다.
요청을 보낸 곳과 받은 곳의 출처가 정확히 일치하는지 확인할 길이 없습니다.
(다음)
https는 앞서 설명드린 http에 데이터 암호화가 추가된 프로토콜입니다.
http와 다르게 443포트를 사용하고, 네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록
ssl 혹은 tls라는 알고리즘을 이용해 내용을 암호화하여 데이터를 전송합니다.
(다음)
HTTPS의 특징으로는 상호 키가 존재한다는 점입니다.
서로 다른 a와 b키를 이용해 데이터를 암호화해서 중간자 공격에 대비하는것인데요,
최초에는 비대칭키 방식으로 대칭키를 공유하고 이후로는 대칭키로 통신합니다.
공개 키를 이용해 데이터를 암호화 하고 비공개키,(개인키)를 이용해 데이터를 복호화 하는 방식입니다.
이 방식을 진행하기 앞서 서버와 클라이언트가 서로 확인하는 handShake를 진행합니다.
클라이언트가 임의의 데이터를 생성해서 서버에 보내면
서버는 응답으로 임의의 데이터와 CA 인증서를 클라이언트에 보냅니다.
클라이언트는 인증서가 진짜인지 브라우저에 내장된 CA들의 정보를 통해서 확인을 합니다.
여기서 CA 썰티피케이트 어썰리티는 엄격한 인증 과정을 거친 인증 기관들의 디지털 인증 기관을 말합니다.
만약 브라우저에 내장된 CA들의 정보와 일치하지 않는다면 브라우저는 안전하지 않을 수 있다는 경고를 보여줍니다.
이로 인해서 중간자 공격에 대비가 가능하고 신뢰할 수 있는 사이트인지를 확인할 수 있습니다.
(다음)
그래서 차이점이 뭐냐
정리하자면
http와 https의 차이점은 보안이라고 할 수 있는데요,
http는 암호화가 추가되지 않았기 때문에 보안에 취약합니다.
반대로 https는 암호화가 추가되어서 안전하게 데이터를 주고받을 수 있습니다.
두 번째로 https를 이용하면 암호화 복호화의 과정이 필요하기 때문에 http보다 속도는 느립니다.
하지만 이는 오늘날에는 거의 체감하지 못할정도의 차이라고 합니다.
https는 인증서를 발급하고 유지하기 위한 추가 비용이 발생합니다.
앞서 말씀드린 CA에서 발급받는 인증서를 이용하기 위해서는 비용을 결제해야합니다.
그래서 보안이 필요한 환경에서는 https를 단순 정보 조회만을 처리한다면 http를 사용하는게 적절하다고 합니다.
(다음)
다음은 cors에 대해서 설명 드리겠습니다.
여러분들은 프로젝트를 진행하면서 이 에러를 본적이 분명 있을겁니다.
이 에러는 CORS 정책에 의해서 발생한 에러인데,
이의 근원은 same origin policy, sop 입니다.
sop는 어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 보안 정책입니다.
(다음)
예전에 웹은 하나의 서버에서 비즈니스 로직과 html 페이지 빌드를 같이 하는 게 일반적이었습니다.
한마디로 같은 서버에서 모든 것이 이뤄졌다는거죠
당시에는 다른 서버로 요청을 날린다고 하면 이는 분명 뭔가 개인정보 유출, 피싱 사이트와 같이
악의적인 행동일 것이라고 의심을 했습니다.
그랬기 때문에 웹 브라우저에서는 같은 출처가 아니면 이를 sop 보안정책으로서 요청 자체를
막는 선택을 하였습니다.
하지만 점점 웹사이트에서 할 수 있는 일이 많아지면서 기존 웹 브라우저 보안 정책 때문에 불편한점들이 생기기 시작했습니다.
예를들어서 날씨 api를 받아오거나 지도 api를 받아야 하는지등이 있습니다.
많은 개발자들은 이 정책을 jsonp라는 방식으로 우회하여 이를 피했습니다.
이러한 현상 때문에 웹브라우저는 특정 조건에 맞는 경우라면 다른 출처라도 리소스 공유가 가능하도록 해주었고 이게 바로 크로스 오리진 리소스 쉐어링 cors 정책입니다.
(다음)
cors는 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근 할 수 있는
권한을 부여하도록 브라우저에 알려주는 체제입니다.
여기서 많이들 착각하는게 앞서 보여드렸던 에러는 cors로 인해서 에러가 발생하는게 아니고
sop로 인해 에러가 발생하는겁니다.
cors는 이를 허용해주기위한 정책입니다.
서버에서는 특정 메소드나 특정 도메인에만 권한을 부여하도록 설정 가능하고,
데이터 통신 시간은 최대 몇초까지 가능하다는 규칙들이 있습니다.
(다음)
만약 웹 애플리케이션을 A라고 하고 다른 출처를 B라고 하면,
A가 B가 가진 자원을 사용하겠다고 요청을 하고,
B는 본인이 정해놓은 허용 기준에 A가 맞는다면 이를 사용할 수 있도록 권한을 주어 허용해 주며,
이를 사용하기 위한 약간의 규칙을 알려준다는 과정이라고 보면 쉽습니다.
(다음)
여기서 이제 A가 요청하는 방식에 대해서 알아봅시다.
이 요청에 대해서는 브라우저가 알아서 다 해줍니다.
그래서 아 이런게 있구나 정도로만 알아도 충분하다고 합니다.
요청 방식은 3가지가 있는데 첫번째로 단순요청 simple Request입니다.
CORS정책에서 브라우저는 기본적으로 preflight 방식으로 요청하도록 합니다.
하지만 일부요청은 preflight방식으로 요청하지 않습니다.
브라우저는 요청을 분석하여 해당 조건을 충족할 때 Simple Request 방식으로 요청합니다.
첫 번째로 HTTP Method가 GET, POST ,HEAD 이 셋 중에 하나로 요청한 경우
(HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.)
두 번째로 Fetch 표준 정책에서 정의한 Forbidden Header Name 이라는 헤더 목록과
콜스 세이펄리스트 리퀘스트 header 라는 헤더 목록 이외에 다른 커스텀 헤더
그리고 권한과 관련된 헤더가 없는 경우를 말하는데
한마디로 커스텀 헤더를 전송하지 않는 경우 입니다.
세 번째로 HTTP Method가 POST인 경우에는
Content-Type 헤더를 수동으로 지정할 수 있는데,
이 Content-Type이 다음과 같은 세 가지 값에 포함되는 경우 입니다.
애플리케이션 엑스 따따따 폼 얼렌코디드
멀티파트 폼데이터
텍스트 플레인입니다.
Simple Request는 서버에 1번 요청하고, 서버도 1번 회신하는 것으로 처리가 종료됩니다.
(다음)
Preflight Request는 비행하기전이라는 뜻으로 쉽게 말하면 이륙 허가를 받는것입니다.
가장 먼저 HTTP Request Method 중 하나인 OPTION 메소드를 교차 출처로 보내고,
응답 받은 헤더 정보를 통해서 메인 요청을 보낼 수 있는지 판단하는 방식입니다.
브라우저는 요청에 origin이라는 header를 추가합니다.
origin에는 오청하는 쪽의 scheme, 도메인, 포트가 담깁니다.
(scheme은 요청할 자원에 접근할 방법)
브라우저는 이 둘을 비교해서 요청할 때 보낸 origin이 응답에 있으면 이를 허용해줍니다.
(다음)
Request with credential은 인증 정보를 포함하여 요청하는 방식입니다.
CORS 요청은 기본적으로 Non-Credential 요청이므로, withCredentials = true를
지정하지 않으면 Non-Credential 요청이 됩니다.
그래서 요청 시 withCredentials = true를 지정해서 Credential 요청을 보낼 수 있고,
서버는 Response Header에 반드시 Access-Control-Allow-Credentials: true를 포함해야 합니다.
Access-Control-Allow-Origin 헤더의 값에는 *가 오면 안되고 http://foo.origin과 같은 구체적인 도메인이 와야 합니다.
이 요청부분이 많이 어려워서 깃헙에 작성할때 더 자세히 알아보도록 하겠습니다.
same-origin이란 scheme(프로토콜), host(도메인), 포트가 같다는 말이며, 이 3가지 중 하나라도 다르면 cross-origin이다.
