졸린눈

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

 더 자세하게 설명하기전에 상위 개념부터 간단히 알아보자.

 먼저  네트워크란 데이터를 교환하기 위해 전송 매체를 매개로 서로 연결되어 있는 것이고 인터넷은 전세계 컴퓨터들이 서로 연결되어있는 거대한 네트워크를 뜻한다.

 사람간의 대화에서 같은 언어를 이용해 의사소통 하듯 네트워크 상에서 데이터를 주고받기 위해서 일종의 정해진 규약이 있는데 이것을 프로토콜이라고 부른다.

 네트워크 상에서 정보를 주고받으려면 어느 경로로 보낼지 어떤 방식으로 데이터를 보낼지 등등 고려해야할 사항이 많다. 만약 하나의 규약을 정해놓았다면 문제가 발생 하였을시 전체를 바꾸어야 하고 또 문제가 발생하기도 쉬울 것이다. 그래서 역할을 나누어 네트워크는 네트워크 계층 구조를 가지게 되었다. 각각의 계층은 모듈단위로 독립적이지만 서로 상호 유기적인 관계를 가진다.

OSI 7계층, TCP/IP 4계층

 TCP/IP 계층을 보면 크게 4개로 나누어져 있고 각각의 계층마다 하는 역할이 다르고 각각의 여러 프로토콜이 존재한다. 이것을 다 알아보는거는 주제에 벗어나는 것 같으므로 TCP가 속해있는 Transport Layer 즉 전송 계층만 간단히 설명하자면

 두 호스트 간에 연결을 맺고 최종적인 통신 목적지까지 데이터를 전달하는 기능을 한다. 

 전송 계층에는 크게 TCP(Transmission Control Protocol) 와 UDP(User Datagram Protocol) 2가지 프로토콜이 있다.

-TCP 연결지향적이며 오류제어, 흐름제어, 혼잡제어, 타이머재전송 등의 기능을 하며 연결지향이란말은 데이타를 전송하는 측과 데이타를 전송받는 측에서 전용의 데이타 전송 선로(Session)을 만든다는 의미이다. 데이타의 신뢰도가 중요하다고 판단될때 주로 사용된다.

-UDP 비연결지향이며, 최소한의 오류제어 기능만 수행한다. 단순히 데이타를 받거나, 던져주기만 하는 프로토콜이다. UDP는 특히 실시간 멀티미디어 정보를 처리하기 위해서 주로 사용한다.

 여기서 딱 보이는 둘의 차이는 연결 비연결이 보인다. 

서두가 길었다. TCP에서 연결지향적인 특성을 갖게 해주는 과정, 방법이 바로 3 Way-Handshake 방식이다.

 간단하게 비유를 들어 설명하자면 a가 b에게 1. b야 내말 잘 들리니?  b가 a에게 2. 응 잘들려 a야 너도 내말 잘 들리니? 3. 응 잘들려! 과 같은 방법으로 서로 의사소통이 할 환경이 잘 구성 되었는지, 즉 연결이 잘 되었는지 확인하는 과정이다.

 네트워크 상에서는 서로 패킷을 주고받아 위 과정을 수행한다. 

 * TCP의 3-way Handshaking 과정

 SYN 은 synchronize sequence numbers ACK는 acknowledgements 의 약자.

[STEP 1]

 A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보낸다. 이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는SYN_SENT 상태  가 되는 것이다.

[STEP 2] 

 이때 서버는 Listen 상태로 포트 서비스가 가능한 상태여야 한다. (Closed :닫힌상태) B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다린다. 이때 B서버는 SYN_RECEIVED 상태가 된다.

[STEP 3]

 A클라이언트는 B서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다. 이때의 B서버 상태가 ESTABLISHED 이다.

 위와 같은 방식으로 통신하는것이 신뢰성 있는 연결을 맺어 준다는 TCP의 3 Way handshake 방식이다.

 출처: http://mindnet.tistory.com/entry/네트워크-쉽게-이해하기-22편-TCP-3-WayHandshake-4-WayHandshake [Mind Net]

 이렇게 3번의 신호를 주고받는다 해서 3-way Handshaking 이다.

                             과정

 1번에 seq넘버를 보내고

 2번에 ack로 1번인 넘버에 1이 추가되었음을 알 수 있다.

 동시에 서버역시 seq넘버를 보낸다

 3번 클라이언트의 ack도 서버가 보낸 seq넘버에 1이 더해졌다

 이런식으로 랜덤한 숫자를보내고 잘받았다는 ack로 1을 더해주는 방식을 사용한다.

 위 방식을 통해 TCP는 연결지향적인 특성과 자체적으로 오류를 처리하며 순서가 뒤바뀐 패킷을 교정해주는 기능이 더불어 주로 데이터의 신뢰도가 중요하다고 판단되어질 때 쓰인다. 

 신뢰도 확보가 중요하거나 용량이 큰 데이터를 전달해야 때, 실시간일 필요는 없을 때 활용 된다.

 하지만 데이터의 신뢰성 보다 전송 속도가 중요시되는 경우면 어떨까? 스트리밍 서비스 같은 경우 속도가 생명이다. 만약 계속해서 버퍼링이 걸린다면 사용자는 매우 불쾌할 것이다. 

 앞서 말한 UDP 프로토콜은 위와 같은 과정이 없이 단순히 데이터만을 전송하므로 속도가 빠르다. 스트리밍  서비스 같은경우 약간의 화질이나 음질의 손상이 있다 해도 끊기지 않는 서비스가 중요하다. 그래서 UDP방식을 사용한다.

 추가++

이 3way handshaking의 취약점을 이용해 서버를 공격 하는 방법이 있는데 이를 SYN Flooding 이라한다

 3way handshaking 과정중 서버는 2단계 에서 (클라이언트로 부터 요청을받고 응답을 하고난후 다시 클라이언트의 응답을 기다리는 상태)  이 연결을 메모리 공간인 백로그큐(Backlog  Queue) 에 저장을 하고 클라이언트의 응답 즉 3단계를 기다리게 되고 일정 시간 (default 로 UNIX/LINUX : 60초 , Windows : 256초 , Apache : 300 초이며 수정 가능) 동안 응답이 안오면 연결을 초기화한다.

 바로 이 점을 이용한 공격법이다.

 악의적인 공격자가 실제로 존재하지 않는 클라이언트IP로 응답이 없는 연결을 초기화 하기전에 또 새로운 연결 즉 1단계 요청만 무수히 많이 보내어 백로그 큐를 포화 상태로 만들어 다른 사용자로 부터 더이상에 연결 요청을 못 받게 하는 공격 방법이다.

대응책으로는 연결 타이머 시간을 짧게 하거나 백로그 큐 사이즈를 늘리는법, 정해진 시간동안 들어오는 연결 요구의 수를 제한하는법, 쿠키(cookie)라는 것을 이용해서 전체 연결이 설정되기 전까지는 자원의 할당을 연기하는 법이 있다..

참조

https://blog.naver.com/ljh0326s/220846406187

http://copycode.tistory.com/30?category=740132

http://www.hoons.net/board/cshaptip/content/35343

https://www.joinc.co.kr/w/Site/Network_Programing/Documents/IntroTCPIP

http://isecure.tistory.com/29

http://tip.daum.net/openknow/13047294

http://www.ktword.co.kr/test/view/view.php?nav=2&id=1104&m_temp1=774

알아보니 먼저 문자집합 (Character Set) 과 인코딩 (Encoding) 의 차이점을 알고 가야 할 것 같다.

 문자집합 (Character Set)은 정보를 표현하기 위한 글자나 기호들의 잡합을 정의한 것이다. 

음 쉽게 말해보면 번호를 매긴 문자들의 집합, 즉 키와 값이 1대1로 매핑 되어있는 것이다. 문자집합의 예로 아스키 코드, 유니코드 등이 있다.

 인코딩(Encoding)은 어떤 형태의 정보를 다른 형태로 바꾸는 것이다. 문자 집합도 일종의 인코딩이다.

 자 그럼 오늘의 토픽 주제인 유니코드와 utf-8,16 은 이렇게 생각해볼 수 있다.

유니코드는 전세계~ 언어를 모두 한 코드체계 안에 담기위해 만들어진 문자집합이고 utf-8,16은 그 유니코드를 사용하는 인코딩 방식이다!

탄생배경

 아주 간단히 말하면.. 초창기의 컴퓨터에는 표준 문자셋이 없었다. 그래서 표준 문자셋인 아스키코드가 나왔다. 하지만 이는 영어표기를 위함이었고 다른 나라의 언어를 사용하기엔 부족했다. 이를 해결하기위해 많은~ 문자셋이 개발 되어 왔고 전 세계 언어를 모두 표현하기 위해 유니코드라는 문자셋이 나오게 되었다. 

현재 유니코드에는 조합 가능한 모든 한글 음절이 수록되어 있다. (19*21*28 = 11,172)

위 그림은 유니코드 인코딩과 타 인코딩과의 관계이다. 

대표적으로  UTF-8 UTF-16 UTF-32 에 대해서 알아보자

 UTF-8 8비트 단위로 인코딩하는 방식이다. 

가변형 인코딩 방식으로 한글자를 1~4바이트로 표현한다. 

 설계원칙 으로 다음 세가지가 있다.

• 1바이트로 표시된 문자의 최상위 비트는 항상 0이다.
• 2바이트 이상으로 표시된 문자의 경우, 첫 바이트의 상위 비트들이 그 문자를 표시하는 데 필요한 바이트 수를 결정한다. 예를 들어서 2바이트는 110으로 시작하고, 3바이트는 1110으로 시작한다.
• 첫 바이트가 아닌 나머지 바이트들은 상위 2비트가 항상 10이다.

변환 과정

 문자 "위" (U+C704) 는 다음과 같이 인코딩된다.

범위상 3바이트 즉 1110xxxx 10xxxxxx 10xxxxxx 형식으로 인코딩된다.

16진수 C704를 2진수로 바꾸면 1100 0111 0000 0100 이다.

이 수를 순서대로  x에 넣는다 11101100 10011100 10000100

이렇게 한글은 3바이트로 인코딩된다. (16진수로 EC 9C 84)

 UTF-8이 이런 성질을 가지도록 설계한 까닭은 어떤 경우에도 한 문자에 대한 바이트 표현이 다른 문자에 대한 바이트 표현의 일부가 되는 경우가 없도록 하기 위함이다.

이러한 설계 원칙 과 가변형 방식이라는 특징 때문에 여러 장점이 있다.

 바이트 경계를 순서대로 혹은 역순으로 찾기 쉽고 첫 바이트만 사용하여 해당 바이트 길이를 결정할 수 있다. 아스키코드 문자열과 호환성이 좋으며 (아스키인코딩은 utf-8의 부분집합, 하위 호환성 보장) 바이트 단위 문자열 검색 알고리즘을 그대로 사용 할 수 있다.

utf-16 과 비교하여 한중일 문자를 안쓰면 최소 2바이트를 사용하는 16보다 더 작은 크기로 표현할 수 있다. 

역으로 utf-16보다 한중일 문자만을 사용 할때는 더 많은 크기를 차지한다.

 UTF-16 16비트 단위로 인코딩하는 방식이다.

 최소 2바이트부터 최대 4바이트까지 인식한다. 기존 다국어 평면(BMP)는 2바이트로 그 이상의 문자는 4바이트로 인코딩이 된다 아스키와 호환이 어렵고 한중일 문자들이 2바이트로 표현되어서 한중일 언어를 인코딩 할 때 에는 utf-8 을 쓸 때 보다 크기가 작아 진다.

  UTF-32 모든 글자를 4바이트로 표현한다.

 모든 문자들을 4바이트로 동일하게 표현한다. 만약 이방식으로 전 시스템이 통일된다면 인코딩 변환이 필요없는 세상이 될 것이다. 하지만 저장공간의 낭비가 심하다는 단점이 있다. 

 저장기술이 더 발전 되어지고 기존 인코딩 방식을 고수하던 프로그램들이 바뀌면 언제가는 UTF-8과 같은 방식으로 통일이 되어지지 않을까? 생각이 든다.

참고 

http://norux.me/31 

https://d2.naver.com/helloworld/19187

http://nuli.navercorp.com/sharing/blog/post/1079940

http://www.allofsoftware.net/2015/06/9.html

Base64 란

 8비트 이진 데이터를 64개의 문자를 이용하여  공통 아스키 문자로 표현하기 위해 만들어진 인코딩 방식이다. 

 Base64를 글자 그대로 직역하면 64진법이라는 뜻이다. 64진법은 컴퓨터한테 특별한데 그 이유는 64가 2의 제곱수 64=2^6이며 2의 제곱수에 기반한 진법 중 화면에 표시되는 ASCII 문자들로 표시할 수 있는 가장 큰 진법이기 때문이다. (ASCII에는 제어문자가 다수 포함되어 있기 때문에 화면에 표시되는 ASCII 문자는 128개가 되지 않는다.)

 구체적으로 A~Z, a~z, 0~9 까지의 62개 문자와 +,/의 2가지 기호가 사용되며 남은 부분은 = 기호로 채워진다. 

 인코딩시 약 33% 정도 데이터의 양이 늘어나는 특징이 있다.

Base64 동작 원리

  24비트 버퍼에 바이너리 데이터를 6비트씩 자르고 6비트를 10진수로 변환한 뒤, 해당 10진수에 대응하는 Base64 색인표에 값을 찾아 치환한다. 24 비트(3바이트)씩 가져오기 때문에 그보다 작은 값이 들어오면 = 으로 채워준다. 이것은 원본으로 되돌릴 때 원본에 없던 비트가 생겨나는 것을 방지하기 위함이다.

위 사진은 a라는 문자를 인코딩하는 예이다. 위 설명과 같이 남은 6비트 2개의 영역을 = (패딩) 처리 해주었다.

쓰이는 이유

 Base64 인코딩을 하게되면 데이터의 양이 약33% 늘어난다. 6비트당 2비트의 오버헤드가 발생하기 때문이다. 이렇게 데이터의 크기가 증가 하는데 왜 쓰일까

 문자를 전송하기 위해 설계된 이메일등에서  이미지나 오디오를 전송 할 필요가있을때, 아스키코드로 인코딩 하게되면 문제가 발생할 수있다. 

 1. 아스키는 7비트 인코딩인데 대부분 8비트로 만들어진 데이터 형태를 갖는다.

 2. 아스키 코드 안에는 화면에 표시되지 않는 제어문자가 포함 되어 있고일부 제어문자 (e.g. Line ending)의 경우 시스템 별로 다른 코드       값을 갖는다.

 위와 같은 문제로 아스키는 데이터 전달하는데에 위험성이 있다. Base64는 아스키중 제어문자를 제외한 64개의 안전한 출력 문자만 사용 하기 때문에 사용 되어 진다.

즉 이메일과 같이 문자를 위한 곳에 이진 데이터로 나타내어질 수 있는 파일을 시스템 독립적으로 동일하게 전송 하기위해 쓰인다 라고 정리 할 수 있을 것 같다. 

 이렇게 base64는 바이너리 데이터를 어느 문자셋에나 있는 아스키코드 기반 기본문자로 인코딩을 해준다. 이렇게 인코딩된 데이터를 받으면 디코딩만 해주면 온전하게 데이터를 받을 수 있는 것이다.

 가장 핵심은 아스키코드 기반 기본문자로만 표현이 되기 때문에 호환성이 좋다는 것 즉 데이터를 온전히 전송 가능하다는 점이다.

어느 시스템에서 어떤 시스템(문자셋) 으로 받던 인코딩 하고 디코딩 해서 받으면 깨짐없이 데이터가 전송 가능하다는 것!

쓰임새

 암호화된 원문을(바이너리파일) 저장,전송 할때 base64로 다시한번 인코딩 하고 쓰인다. 암호화된 파일도 어딘가에는 저장이 필요할 텐데 저장을 돕는 프로그램도 (db) 어느 문자셋을 기반으로 할 것이고 그럼 그곳에 바이너리 파일 그대로를 넣으면 데이터는 깨지게 될 것이다. 하지만 암호화된 파일(바이너리)을 다시한번 base64로 인코딩하면 식별가능한 아스키코드 기반 기본문자로 바뀌고 이것을 저장하면 문제가 생기지 않는다.

 예를 들어 사용자 비밀번호와 같은 데이터는 DB에 저장 될 때 원문 그대로가 아닌 암호화(단방향 암호화) 되어 저장 되어지는 것이 필요하다. 데이터 유출시 비밀번호 유출을 막기 위함이다. DBMS는 사람이 보고 인식하는 곳으로 지정된 문자셋이 있는데  이때 sql문으로 데이터를 넣을때 암호화된데이터(바이너리)를 그대로 넣으면 정해진 DBMS 문자셋 에 의해 암호화된데이터가 깨지게 된다. 그래서 암호화된데이터를 한번더 base64로 인코딩 해주고 DBMS에 넣으면 관리가 용이해진다.

 여담- 단방향 암호화= 원문을 암호화하는 알고리즘은있지만 이를 복호화하는 키가 없는 기법. 

사용자의 비밀번호를 단방향 암호화로 저장하고 (유출방지) 다시 사용자가 비밀번호를 입력할때 입력된 비밀번호를 암호화하고 초기에 설정된 암호화된 비밀번호랑 비교하는 방식으로 검증을 하면 된다.

참고 

http://effectivesquid.tistory.com/26

https://okky.kr/article/276104

JVM 

  JVM(Java Virtual Machine) 자바 가상 머신 이라 불리며 컴파일된 바이트코드 파일을  읽어 실행 시키는 역할을 한다.

우선 대략적인 자바 실행 과정을 설명하면 사용자가 1.텍스트형태에 자바코드를 만들면 (.java)  2.컴파일러에 의해서 바이트코드로 컴파일 되고(.class) 3.이는 각각의 os에 맞는 JVM(자바 가상 머신)이 메모리를 할당 받고 실행 가능하도록 기계어로 해석하여 준다.

  JVM 부분을 조금더 자세히 설명하면 Runtime Data Area(JVM 메모리 영역)에 메모리가 할당되면 Class Loader가 Byte Code(.class)파일을 그곳에 로드하고 배치한다. 그리고 Execution Engine가 그것을 해석하고 실행시킨다.

 메모리는 한정되어 있으며 메모리의 효율적인 관리는 프로그램에 성능을 좌우하기 때문에 메모리 구조를 정확히 이해하고 메모리 관리를 하는 것이 필요하다.

JVM 메모리 구조

Runtime Data Area영역은 크게 3가지로 나뉘어 진다. 

1. 메소드 영역 (Method Area) 

같은 뜻으로 Class Area, Code Area, Static Area가 있다.

 여기에는 런타임 상수풀, 멤버 변수, 클래스 변수, 생성자와 메소드와 같이 클래스와 인터페이스에 관련된 데이터를 분류하고 저장한다.

JVM 시작시 생성 되며 프로그램 종료시까지 유지된다. 그러므로 멤버 변수는 어디에서든 사용이 가능하다. 

2. 힙 영역 (Heap Area)

 실행시 동적으로 할당하여 사용하는 영역이다. New 연산자로 생성된 객체나 배열을 저장한다. 여기에 생성된 객체와 배열은 스택 영역의 변수나 다른 객체의 필드에서 참조한다. 만약 참조하는 변수,필드가 없으면 Garbage Collector에 의해 메모리 반환된다.

3. 스택 영역(Stack Area) 혹은 call stack

 메소드 호출 시 생성되어지는 영역이다. 지역변수, 매개변수, 연산중 나오는 임시데이터 등이 저장된다. 메소드가 종료되면 해당 영역은 비워진다. 기본 타입 변수는 스택 영역에 직접 값을 가지며 참조 타입 변수는 힙 영역이나 메소드 영역의 객체 주소를 가진다. 

각 메소드당 메모리상의 공간은 구별되며 처음 호출된 메소드의 공간이 마련되고 그 메소드 수행 중에 다른 메소드가  호출되면 첫번째 메소드 수행을 멈추고 그위에 두번째 메소드를 위한 공간이 마련되고 두번째 메소드를 우선 수행한다. 수행을 마치게 되면 그 메소드를 위한 공간이 비워지고 아까 수행중이던 메소드를 다시 수행한다. 

예를 들어 보면은~

//1 번 까지의 상황이다 

args[]에 값 두개를 넣었다 10,20 

args 라는 자체는 스택영역에 있지만 참조 되어지는 배열은 힙영역에 들어간다.

//2 번 까지의 상황이다

 add메소드는 이미 수행이 끝나고 multi메소드가 수행된 상태이다.

 total 변수는 클래스 변수로 메소드 영역에 있어 어느 메소드에서나 접근이 가능하다 add()와 muiti() 메소드들의 ++total 을 수행하여 2가 되었다.

 add()의 수행값을 sum에 넣어 sum값이 30 multi()의 수행값을 multi에 넣어 multi값이 200이 되었다.

 multi메소드가 수행할때에는 매개변수 a,b에 메인 메소드의 지역변수 x,y 값이 대입되어 각각 10 20 값을 가졌다. 이는 종료후 사라질 것 이다.

번외)

이클립스에서 인자값 주는법

위 사진처럼 Program arguments 칸에 넣으면 된다.

추가적인 내용으로 위에 사진에 보이는 VM arguments 칸은 사용자가 직접 JVM메모리의 용량을 설정해 주는 것이다.

-Xmx<size> 초기의 Heap size   -Xms<size> 최고 Heap size    -Xss<size> Stack size   

 설정값의 종류이다. 힙사이즈는 초기값과 최고값이 정해져있다. 동적으로 크기가 변함을 알 수 있다. 하지만 최초 크기와 최대 크기를 동일하게 부여할 것을 권장한다. 크기의 동적인 변경에 의한 오버 헤들를 최소화하기 위해서이다

 -Xms1024m-Xmx1024m-Xss512m  과같이 넣으면 된다.

참조:  http://hoonmaro.tistory.com/19

        http://limkydev.tistory.com/51

        http://atin.tistory.com/625

  https://blog.naver.com/kimso612/110028382119

  http://hyoje420.tistory.com/2