후니훈의 모바일 세상

1. HTTP 기본 구조(HTTP 1.0 이하)

- 파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

- 빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

위 그림(Wire Shake 예제)에서와 같이 HTTP는 기본적으로 Connection-Less 방식을 가진다. 즉 맷어진 Socket 연결은 유지되지 않고 매번 끊어지며, 다시 생성 되는 구조이다.

웹 서버 상세 처리 과정:

http://mohwaproject.tistory.com/entry/%EC%A0%95%EC%A0%81%EB%8F%99%EC%A0%81-%ED%8E%98%EC%9D%B4%EC%A7%80-%EC%9B%B9-%EC%84%9C%EB%B2%84-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95

2. Keep-Alive(HTTP 1.1 이상) 기능 이란?

위 HTTP 기본 구조를 바탕으로 맷어진 Socket 연결이 종료된 시점(HTTP Response 이후)부터 웹 서버에 정의된 Keep-Alive Timeout 까지 기존 연결(Socket)을 유지하는 기능.

즉, 정의된 시간(Keep-Alive Timeout) 내에 새로운 HTTP 요청이 발생한다면? 맷어진 Socket 연결을 지속적으로 유지할 수 있다.(앞서 말한바와 같이 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다.)

- IIS 테스트 결과 정의된 시간의 50% 이상 일찍 끊어진다.(120초 / 2)

3. IIS(6 / 7) Keep-Alive 설정 방법

- IIS 6: 

1. Keep-Alive 활성화 설정 및 Keep-Alive Timeout 정의

- 연결 시간 제한은 기본 120초를 갖는다.

- IIS 7:

1. Keep-Alive 활성화 설정

2. Keep-Alive Timeout 정의

- 연결 시간 제한은 기본 120초를 갖는다.

4. 웹 서버 HTTP Connection 변화

- Keep-Alive 비활성화 시:

1. 아래 예제와 같이 맷어진 HTTP Connection(Socket 연결)은 유지되지 않고 바로 끊어진다.(Current Connection 0.000)

2. Response-Header Field인 Connection 값으로 "close" 를 응답한다.

- Keep-Alive 활성화 시:

1. 아래 예제에서와 같이 맷어진 HTTP Connection(Socket 연결)은 유지된다.(Current Connection 1.000)

- 지속적인 연결은 유지되나 정의된 Keep-Alive Timeout(120초)  시간은 정확히 지켜지지 않는다.(보통 정의된 시간보다 Socket 연결이 일찍 끊어진다)

2. Response-Header Field인 Connection 필드는 존재하지 않는다.(IIS 기준)

5.  Wire Shake를 통해 본 Keep-Alive 처리 과정

- 파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

- 빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)

- Keep-Alive 처리 과정

1. HTTP Session(논리적 연결) 생성

2. 정의된 Keep-Alive Timeout 내에 새로운 HTTP 요청이 발생할 경우, 새로운 Socket을 재 생성하는 것이 아닌 활성화 된 Keep-Alive 기능을 통해 유지된 Socket 연결에 Request하게 된다.

즉, Socket 연결에 필요한 모든 비용이 감소하게 되며, 그에 따라 전체적인 성능도 좋아지게 된다.

3. 클라이언트(브라우저)와 웹 서버는 HTTP Request 및 Response를 수행한다.

4. 정의된 Keep-Alive Timeout 동안 맷어진 Socket 연결은 지속적으로 유지된다.

5. HTTP Session Close

- 클라이언트(사용자) 접속 종료 시 서버에 적재된 HTTP Session은 소멸된다.

- Keep Alive Timeout(연결 유지 시간) 종료 시 처리 과정

- 파란 테두리: 첫 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정

- 빨간 테두리: 두 번째 Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(Keep-Alive 활성화 시 HTTP 기본 구조와 달리 TCP 세션 수립과정 중 일부가 생략 되었다는걸 볼 수 있다.)

- 주황 테두리: Socket(TCP) 연결 및  HTTP Request/Response 처리 과정(정의된 Keep-Alive Timeout(연결 유지 시간) 종료 시  첫 번째 요청과 같이 TCP 세션 수립과정 이 다시 발생하게 된다.)

출저: http://mohwaproject.tistory.com/entry/Wire-Shake%EB%A5%BC-%ED%86%B5%ED%95%B4-%EB%B3%B8-KeepAlive-%EC%B2%98%EB%A6%AC-%EA%B3%BC%EC%A0%95

TCP 세션 수립 과정

이번 포스트에서는 SSL 동작 방식에 앞서 패킷 교환 방식의 기본인 TCP 3 Way Handshake에 대해서 알아보도록 하겠습니다.

TCP 3 Way Handshake의 정의:

송신 측과 수신 측이 서로 교환할 패킷을 위해 총 3개의 패킷을 주고받으며, 서로에 대한 전송을 보장하는 세션을 수립하는 

과정입니다.

아래는 TCP 3 Way Handshake 과정을 대략적으로 도식화 한 그림 입니다.

TCP 3 Way Handshake 에 대한 상세 과정은 아래와 같습니다.

송신 측 호스트(211.254.99.210(클라이언트))

수신 측 호스트(203.242.213.203(웹서버))

1. 송신 측은 수신 측과의 통신을 원하고 있음을 알리는 신호로 TCP 헤더의 SYN(Synchoronize) Flag를 활성화(1)하고, 패킷에 일련번호(S/N(seq = 0))를 붙어 상대방에게 알려줍니다.

2. 이때 수신 측은 송신 측 SYN(Synchoronize)Flag 신호에 대한 응답 패킷 생성에 들어가기 위해, ACK(Acknowledgement)Flag를 on 시키고, 송신 측 일련번호(S/N(seq = 0))에 1을 더한 응답(A/N(ack = 1))값과 

자신의 일련번호(S/N(seq = 0))를 발송합니다. 또한, 이 과정은 송/수신 측의 양방향 세션이 수립되었음을 의미합니다.

3. 송신 측은 수신 측에게 두 번째 패킷(ack 및 일련번호(S/N(seq = 1) == (수신 측에게 받은 ack = 1 값))에 대한 응답을 주며, 이때부터 양 방향 패킷 교환이 시작되는 것입니다.

아래는 송/수신 간에 패킷 교환이 이루어지는 과정입니다.

송/수신간에 세션 수립(TCP 3 Way Handshake) 과정이 끝난 후 송신 측이 수신 측에게 GET요청을 보내고 있으며, 그에 따른 응답 메시지가 전송되고 있습니다.

위와 마찬가지로 송신 측의 GET 요청에 대한 응답 메시지가 전송됩니다.

페이지의 구성요소(js, css, img 등)이 요청됩니다.

웹서버가 클라이언트에게 HTML 응답 패킷을 전송합니다.

출저

http://mohwaproject.tistory.com/entry/TCP-3-Way-HandshakeTCP-%EC%84%B8%EC%85%98-%EC%88%98%EB%A6%BD

들어 가면서

HTTP는 아시다 시피 connection less 방식으로 연결을 매번 끊고 새로 생성하는 구조입니다. 이는 network 비용측면에서 많은 비용을 소비하는 구조입니다.( 최초 연결하기 위한 준비과정을 의미함 ) 그래서 HTTP 1.1부터는 Keep-Alive라는 기능을 지원합니다.

Keep Alive란?

Keep Alive란 연결된 socket에 IN/OUT의 access가 마지막으로 종료된 시점부터 정의된 시간까지 access가 없더라도 대기하는 구조입니다. 즉 정의된 시간내에 access가 이루어진다면 계속 연결된 상태를 유지할 수 있다는 것 이죠.

HTTP 下에서 Keep Alive란?

HTTP는 앞서 설명드린 것과 같이 connection less방식이라 매번 socket(port)를 열어야 하고 이는 비용적인 측면에서 비효율적인 구조입니다. 해서 keep Alive time out내에 client에서 request를 재 요청하면 socket(port)를 새로 여는 것이 아니라 이미 열려 있는 socket(port)에 전송하는 구조가 됩니다.

예를 들면 image를 4개를 보여주는 구조에서 client는 동시에 2개의 image만 얻어 올수 있고 1개의 image는 얻는데 2초 걸리고 port를 여는데 1초가 걸린다고 가정.

keep alive : false 

처음 server에 2개의 port를 열고 image를 얻고 client socket의 닫고 ( 3초 ) 

다시 server에 2개의 port를 열고 image를 얻고 client socket을 닫음 ( 3초 ) 

총 6초가 걸림.

keep alive : true 

처음 server에 2개의 port를 열고 image를 얻고 ( 3초 ) 

다시 첫번째 요청에서 열어 둔 2개의 port에 2개의 image를 얻음 ( 2초 ) 

keep alive time out이 되었을 때 client의 socet이 닫히거나 browser가 더 이상 얻어 올 것이 없으면 자동으로 닫어 버림. 

총 5초가 걸림.

Keep Alive를 그럼 어떻게 쓸수 있는가?

딱, 잘라서 말하면 개발자 영역에서 할 부분은 전혀 없습니다.

client(browser)는 http 1.1을 준수하고 이해 할수 있다고 request에 Connection: Keep-Alive를 넣어서 Server에 전송 

즉 client는 http 1.1 spec을 구현하고.. 

server도 http 1.1 spec을 구현하고 keep alive 기능을 활성화하고 keep alive time out을 설정

참고

client에서 keep alive code를 보내고 server도 kepp alive 기능을 제공할 경우.

$ telnet pungjoo.com 80

Trying 121.124.124.74...

Connected to pungjoo.com.

Escape character is '^]'.

GET / HTTP/1.1

Host: pungjoo.com

Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:32:45 GMT

Set-Cookie: JSESSIONID=91569ADEF9D501B8071BD59D0DC04E82; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

Connection to pungjoo.com closed by foreign host.

위에 Connection to pungjoo.com closed by foreign host. 메시지가 바로 나오는 것이 아니라 5초 후에 나오게 됩니다.

즉 server/client의 구간은 지속됨을 알수 있습니다.

$ telnet pungjoo.com 80

Trying 121.124.124.74...

Connected topungjoo.com.

Escape character is '^]'.

GET / HTTP/1.1

Host: pungjoo.com

Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:36:26 GMT

Set-Cookie: JSESSIONID=2B3EE2FE56868BD9588A7B55C405974B; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

GET / HTTP/1.1

Host: pungjoo.com

Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:36:35 GMT

Set-Cookie: JSESSIONID=E4E3D9B9CFE3693DC5AFC3D6ABDE5564; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Keep-Alive: timeout=5, max=99

Connection: Keep-Alive

Connection to pungjoo.com closed by foreign host.

위 예제를 보시면 알겠지만 telnet(연결)은 한번 사용했고 GET method를 2번 날렸습니다. 즉 이렇게 할수 있는 이유는 keep alive 기능때문에 가능한 것 입니다.

참고로 보면 Keep-Alive: timeout=5, max=99 부분에서 max가 감소를 하는 것을 볼수 있는데 이는 최초 연결된 port에 대해서 100회 request를 받겠다는 의미입니다.

HTTP1.0으로 해 보겠습니다. 즉 keep alive 기능이 없음.

$ telnet pungjoo.com 80

Trying 121.124.124.74...

Connected to pungjoo.com.

Escape character is '^]'.

GET / HTTP/1.0

Host: pungjoo.com

HTTP/1.1 302 Moved Temporarily

Date: Tue, 15 Jan 2008 01:33:56 GMT

Set-Cookie: JSESSIONID=B4329BFEDB1363BB90FCFA9568DDBF0B; Path=/

Location: http://pungjoo.com/servlet/com.pungjoo.blog2005.Action

Content-Type: text/html;charset=EUC-KR

Content-Length: 0

Connection: close

Connection to pungjoo.com closed by foreign host.

이번 경우는 response가 날라 오고 바로 'Connection to pungjoo.com closed by foreign host.'로 나와 버립니다. 즉 바로 server/client에서 끊어 버립니다.

출저: http://pungjoo.tistory.com/2

. ① 장기판 장기

판은 보통 가로 70cm, 세로 60cm 정도의 네모난 나무판에 10cm 정도의 다리를 네 귀에 달아 만든다. 판에는 가로 열줄·세로 아홉줄의 선을 긋는데, 

홈을 가늘게 파고 홈안에 먹칠을 하는 것이 보통이었다.② 장기쪽장기쪽은 두 편이 꼭같이 각각 16개인데, '궁' 또는 '왕' 1개, '차' 2개, '마' 2개, '

상' 2개, '포' 2개, '사' 2개, '졸' 5개로 이루어져 있다. 장기쪽의 기호와 수는 양편이 같기 때문에 8각형의 나무토막에

Android Support Library 가 업데이트 되면서 v7 Support Library에 하위 호환성을 가진 ActionBarActivity 가 추가되었습니다. 이 라이브러리가 나오기 전에는 ActionBarShelock을 이용해서 3.0 미만 버전에서 ActionBar를 사용할 수 있었지만 v7 라이브러리를 사용하면 구글에서 제공해주는 라이브러리를 통해서 ActionBarShelock를 사용할 수 있습니다. v7 라이브러리 중 v7 appcompat을 사용하면 ActionBarActivity를 사용할 수 있습니다. 이것에 대해서 아래 Development 문서에 자세하게 나와 있습니다.

 v7 라이브러리 불러오는 법 : http://developer.android.com/tools/support-library/setup.html

 개발 문서에는 이클립스에서의 적용법과 Android Studio에서의 적용법 2가지가 나와있습니다. Android Studio에서의 적용법은 아주 간단하게 추가가 가능하지만 이클립스는 2개의 프로젝트를 필요로 합니다. 1 번째 프로젝트는 v7 appcompat 소스코드를 불러와서 라이브러리 형태로 만들고, 사용해야할 프로젝트를 생성하여 라이브러리를 include 하는 방식으로 사용하게 됩니다.

 저는 이클립스에서 라이브러리르 호출하는 방식으로 간단하게 액션바를 사용하는 예제를 작성합니다.

ActionBar Compat 예제 실행 및 Lib

 ActionBar Compat 예제를 불러오기 전에 안드로이드 SDK를 최신으로 업데이트하시면 됩니다. SDK Manager에서 Extras -> Android Support Library와 안드로이드 4.3 또는 4.2.2의 Sample Project를 다운로드 받으시면 됩니다.

 ActionBar Compat 예제를 먼저 불러와야 합니다. 불러오는 방법은 2가지가 있습니다. v7 라이브러리 사용법을 설명하는 개발 문서에서의 방법이 하나 있고, Sample Project를 불러와서 처리하는 방법 2가지가 있습니다. 이 글에서는 Sample Project를 불러와서 처리하는 방법을 설명하겠습니다.

 새로운 프로젝트 File -> New -> Other... 을 선택하시고, Android의 Android Sample Project를 선택합니다.

 최신으로 업데이트한 Android 4.3의 Sample Project를 선택하겠습니다.

 아래와 같이 Select Sample의 lagacy > ActionBarCompat 프로젝트를 선택합니다.

 생성된 프로젝트는 아래와 같습니다. 이 프로젝트를 불러와서 라이브러리 형태로도 사용이 가능하며, 해당 프로젝트에는 예제 코드가 들어있어 바로 실행도 가능합니다. ActionBarCompat 예제는 아래와 같이 파일이 추가되어있습니다.

 2.3.3에서 실행하면 아래와 같은 결과를 얻을 수 있고, 4.3에서 실행해도 동일한 UI의 ActionBar를 볼 수 있습니다.

라이브러리로 변경

 해당 프로젝트의 설정으로 들어갑니다. 오른쪽 마우스를 클릭하고, Properties를 선택하고, 메뉴에서 Android를 접속합니다.

 아래의 Is Library 를 선택하신다음 OK를 누르시면 라이브러리로 사용이 가능합니다.

새로운 프로젝트에 적용

 새로운 프로젝트에서 ActionBarActivity를 사용할 수 있습니다. 위에서 라이브러리로 사용하도록 설정하였으니 여기에서 그 라이브러리를 불러와서 사용하면 됩니다. 새로 만든 프로젝트에서 오른쪽 마우스의 Properties를 선택하고, Android 탭으로 이동합니다. 여기에서 Add... 버튼을 클릭합니다.

 위에서 적용한 라이브러리의 체크 하지 않으면 보이지 않으니 다시 라이브러리를 추가하시면 됩니다. ActionBarCompat를 선택하여 추가합니다.

 아래와 같이 추가되었습니다. 이제 Activity를 상속받는 Class를 ActionBarActivity로만 변경하시면 됩니다. 100% 코드 그대로 사용이 가능하기에 상속받는 메소드 명만 변경하면 됩니다.

ActionBarActivity 코드

// ActionBarActivity를 추가하면 아래와 같이 실행됩니다.
import com.example.android.actionbarcompat.ActionBarActivity;

/* 
 * Activity를 ActionBarActivity로만 변경하시면 됩니다.
 * 기존 코드 그대로 v7 라이브러리만 추가되면 모두 동일하게 사용할 수 있습니다.
 * /
public class MainActivity extends ActionBarActivity {

	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.activity_main);
	}

}

ActionBarActivity를 적용한 예제

 2.3.3에서 ActionBarActivity를 적용한 예제입니다. 아래와 같이 실행되며, 4.3에서 실행해도 동일하게 볼 수 있습니다.

마무리

 ActionBarShelock를 적용하는 예제를 작성하려고 했으나 밀리고 밀려서.. 결국 v7 라이브러리의 ActionBar 적용법을 작성하게 되었습니다. ActionBarShelock를 적용하면 조금 많은 메소드가 변경이되어야 하지만 v7 라이브러리는 안드로이드의 기존 코드 그대로 쉽게 적용이 가능하다는 장점이 있습니다. C:\android-sdk-windows\extras\android\support\v7\appcompat\libs 의 경로에 보시면 android-support-v7-appcompat.jar 있기는 하지만 제가 실수를 한건지 동작하지 않아서 이 방법으로 글을 작성해보았습니다.

출저: http://thdev.net/m/post/487